Tools Nimbus

Base64 vs Base64URL: what is the difference

Tools Nimbus is a free, no-signup developer toolkit that runs entirely in your browser, so your data is never uploaded to a server. Base64 and Base64URL are the same encoding with three character swaps: Base64URL uses - instead of +, _ instead of /, and usually drops the = padding so values survive URLs and file names. You can try both directions with the Tools Nimbus Base64 Encoder and Decoder.

Last updated June 2026

One encoding, two alphabets

Base64 turns arbitrary bytes into text by slicing them into 6-bit groups and mapping each group to one of 64 characters. The first 62 characters are uncontroversial: A to Z, a to z, and 0 to 9. The disagreement is the last two. Standard Base64, defined in RFC 4648 section 4, picks + and /. Base64URL, defined in section 5 of the same RFC, picks - and _ instead, because + and / both carry meaning inside URLs. Everything else about the two variants is identical: same 6-bit slicing, same character order, same decoded bytes.

Side by side

PropertyBase64 (standard)Base64URL
Defined inRFC 4648, section 4RFC 4648, section 5
63rd character+- (hyphen)
64th character/_ (underscore)
PaddingRequired (= to a multiple of 4)Usually omitted
Safe in URL query stringsNo (needs percent-encoding)Yes
Safe in file namesNo (/ is a path separator)Yes
Typical usesEmail attachments (MIME), data URIs, HTTP Basic authJWTs, OAuth and PKCE values, URL tokens, file names

Why the two characters matter in practice

Inside a URL, + is decoded as a space in query strings, / separates path segments, and = separates parameter names from values. Put a standard Base64 string in a query parameter and all three can be reinterpreted by servers, proxies, and logging middleware. The classic symptom is a token that validates locally but arrives broken: its + characters became spaces somewhere in transit. Percent-encoding every offending character works, but it is easy to forget and double-encoding bugs are worse. Base64URL sidesteps the whole class of problems, which is why every token format designed for transport in URLs or headers uses it.

Padding: why lengths must be a multiple of 4

Base64 emits 4 output characters for every 3 input bytes, so when the input length is not a multiple of 3, the standard variant appends one or two = signs to round the output up to a multiple of 4. The padding carries no data; decoders use it only to confirm the length. Base64URL conventions usually drop it, since = is another character with meaning in URLs and the length can be inferred. This is the detail that bites when you move strings between systems: a strict decoder handed an unpadded string refuses it with an invalid length error. The repair is mechanical, append = until the length is a multiple of 4.

How to recognize and convert each form

Reading a token tells you which variant you have. Any - or _ means Base64URL; any +, /, or trailing = means standard Base64. A string with neither set is valid in both and decodes identically either way. Converting is a character swap, no re-encoding involved: replace - with + and _ with /, fix up padding, and decode as standard Base64. The Base64 Encoder and Decoder handles ordinary Base64 text in your browser with UTF-8 and emoji support, so nothing you decode is uploaded anywhere. For the specific case of JSON Web Tokens, the JWT Decoder splits the three Base64URL segments and pretty-prints the header and payload in one step.

Neither one is encryption

A surprising number of real-world bugs trace back to treating Base64 as a security measure. It is a representation, not a cipher: there is no key, and decoding requires nothing but a decoder. Session data, credentials, and personal information inside a Base64 or Base64URL string are fully readable by anyone who obtains the string. The encoded payload of a JWT, for example, is public to whoever holds the token; only the signature is cryptographic. If data must be secret, encrypt it, then Base64-encode the ciphertext for transport if you need text.

Frequently asked questions

What is the difference between Base64 and Base64URL?+

They are the same encoding with three character differences. Standard Base64 uses + and / in its alphabet and pads output with =. Base64URL replaces + with a hyphen (-), / with an underscore (_), and usually drops the = padding, so the result can travel inside URLs, file names, and form fields without percent-encoding.

Why does my Base64 string break when I put it in a URL?+

Because + means a space in URL query strings and / starts a new path segment, while = delimits parameters. A standard Base64 value containing those characters gets mangled or misparsed unless every one is percent-encoded. Base64URL exists precisely so the encoded value passes through URLs untouched.

Are JWTs Base64 or Base64URL?+

Base64URL. Each of the three dot-separated segments of a JSON Web Token is Base64URL-encoded without padding, which is why a generic Base64 decoder can choke on a JWT segment containing - or _. Decode JWTs with a JWT-aware tool or convert the alphabet first.

Does Base64 encryption protect my data?+

Base64 is not encryption and provides zero secrecy. It is a reversible text representation of bytes that anyone can decode instantly. Never treat an encoded value as protected; it is exactly as readable as plain text to anyone who receives it.

Why is my decoded Base64 garbled or failing with an Invalid character error?+

The two most common causes are alphabet mismatch (the string is Base64URL with - and _ but the decoder expects + and /) and missing padding (the decoder demands a length that is a multiple of 4). Translate the characters, re-add = padding to a multiple of 4, and decode again.

Try these browser-based tools mentioned in this guide. Everything runs locally, so your data never leaves your device.