Encode or decode both variants locally with the Multi-Format Encoder.
What Base64 actually is
Base64 turns binary data into ASCII using 64 characters: A–Z, a–z, 0–9, plus + and /. A final = is used as padding so the output length stays a multiple of 4.
It is an encoding, not an encryption. Anyone can decode Base64 without a key. Its job is to carry binary data through text-only channels such as email, JSON, or URLs.
Every three input bytes become four output characters: 24 bits split into four 6-bit groups, each picking one of the 64 alphabet characters. That is why the output runs about a third longer than the input.
In the browser, btoa() and atob() only accept single-byte (Latin-1) strings. Feed them emoji or other UTF-8 text and they throw or return garbage, so convert text to UTF-8 bytes first, for example with TextEncoder.
Why URLs break standard Base64
The 62nd and 63rd alphabet characters, + and /, are not URL-friendly. In a query string, + is interpreted as a space, and / can split a path segment.
Padding = also causes trouble: it is sometimes stripped by parsers, and it is often removed in compact formats such as JWTs.
Percent-encoding can patch this, but every layer that decodes the URL must agree on the escaping, and double-encoding bugs creep in easily. Replacing the two alphabet characters removes the problem at the source.
- + is read as a space in query strings
- / terminates or splits a path segment
- = padding is stripped by some parsers and token formats
Side by side
Only two characters differ, and the decoded bytes are identical either way. Swap + for - and / for _, drop the = padding, and you hold the Base64URL form of the same data.
The padding row deserves a closer look: standard Base64 is defined with padding, while Base64URL leaves it optional and compact formats such as JWT omit it.
| Property | Base64 | Base64URL |
|---|---|---|
| 62nd character | + | - |
| 63rd character | / | _ |
| Padding | Required | Usually stripped |
| Typical use | Email MIME, data URIs | JWT, filenames, query strings |
| Decoder compatibility | Widest support | Requires url-safe handling |
When to use which variant
In practice, JWT segments are the Base64URL you will see most often, since header, payload, and signature each arrive unpadded. When I had to decode a JWT payload in a CI script, picking the URL-safe decoder fixed it in one line.
- Use Base64URL for JWT header and payload segments, filenames, and anything embedded in a URL
- Use standard Base64 for MIME email attachments and data that never touches URLs
- When in doubt, prefer Base64URL in web applications and standard Base64 in legacy formats
Note: The two differ only in the alphabet and padding. A JWT segment is Base64URL without padding; do not paste padding back in when decoding.
Encode and decode locally, step by step
The tool shows padded and unpadded output, and the decoder accepts both, so you can paste a JWT segment as-is into the Multi-Format Encoder.
- Open the Multi-Format Encoder in your browser.
- Choose Base64 or Base64URL from the encoding options.
- Paste your text or file content and encode it.
- Switch to the decoder and paste the result to verify round-trip integrity.
FAQ
Q.Is Base64URL still Base64?
A.Yes. It uses the same idea and the same padding rules; only two alphabet characters change (- and _ instead of + and /) so the output survives URLs and filenames. The decoded bytes are identical, and most standard libraries ship a URL-safe variant, such as Node's Buffer, Python's base64 module, or Go's base64 package.
Q.Does Base64URL need padding?
A.Padding is optional in Base64URL and usually stripped in compact formats like JWT. Decoders accept both padded and unpadded input, since the output length is derivable from the data (a multiple of 4). You rarely add it by hand, because a decoder re-adds it for you. One caveat: the browser's atob() expects padded standard Base64, so convert Base64URL to the standard form first.
Q.Is Base64URL more secure than Base64?
A.No. Both are encodings with zero secrecy; the alphabet choice changes nothing about confidentiality. Base64URL only avoids URL parsing problems. When confidentiality matters, use real encryption such as AES-256-GCM and encode the ciphertext with Base64URL if it has to travel inside a URL. Treat Base64URL as a transport format, not a hiding mechanism.
References
- RFC 4648 – The Base16, Base32, and Base64 Data Encodings: https://www.rfc-editor.org/rfc/rfc4648
- RFC 7515 – JSON Web Signature (JWS): https://www.rfc-editor.org/rfc/rfc7515
- MDN – btoa(): https://developer.mozilla.org/en-US/docs/Web/API/Window/btoa
Base64URL for URLs, Base64 for MIME
Put Base64URL wherever the data will touch a URL, a filename, or a JWT header. Keep plain Base64 for MIME email and formats that never see a URL.
Neither variant hides anything, so encrypt sensitive content separately with the AES-256-GCM Encryptor and encode it afterward with the Multi-Format Encoder.
A quick habit that saves time: a string containing + or / is standard Base64, one containing - or _ is Base64URL. One glance tells you which decoder to reach for.