Base64URL represents the same bytes as Base64 with a different alphabet for two characters. To decode a URL-safe string, replace - with + and _ with /, then restore padding when the receiving format allows it. Decodex accepts both formats and displays the result as UTF-8 text.
What actually changes?
Standard Base64 uses letters, digits, + and /. Base64URL uses the same letters and digits but replaces + with - and / with _. Padding is a separate decision: Base64URL may include =, or a protocol may specify its omission. A string containing only letters and digits cannot tell you which alphabet the sender intended.
A verified example: one emoji, two representations
The emoji 😀 is four bytes in UTF-8, so its padded Base64 form is 8J+YgA==. The URL-safe padded form is 8J-YgA==, and its unpadded form is 8J-YgA. All three decode to the same emoji in Decodex. The comparison table below shows both padded forms; use the example link to test the unpadded form.
Why URLs and form fields cause problems
In application/x-www-form-urlencoded data, a + character can be interpreted as a space. A / character can also conflict with a path separator when embedded in a URL path. Base64URL avoids these two characters. It does not replace proper URL construction: use URLSearchParams or an appropriate URL API instead of concatenating unescaped values. If a + was already replaced with a space, a decoder cannot reliably reconstruct the missing data.
How to convert between the formats
To create unpadded Base64URL, first encode the original bytes as Base64, replace + with - and / with _, then remove only trailing = characters if the target protocol allows it. For decoding, normalize the alphabet and add the required trailing padding. Do not remove internal characters or assume every service accepts both forms. Decodex encodes standard padded Base64; it accepts Base64URL on the decoding page.
JWT segments are not proof that a token is safe
The header and payload of a signed JWT commonly use unpadded Base64URL. Decoding a segment can show its text, but it does not verify a signature, expiry or permissions. The signature segment is binary and should not be expected to decode as UTF-8. This page does not validate JWTs; never share a real access token just to test decoding.
Try this example
| Format | Text | Base64 |
|---|---|---|
Base64 | 😀 | 8J+YgA== |
Base64URL | 😀 | 8J-YgA== |
Base64URL (JWT) | 😀 | 8J-YgA |
Common questions
Is Base64URL encryption?
No. Both formats are reversible encodings of bytes. Changing the alphabet does not hide sensitive data.
Does Base64URL always omit =?
No. Padding depends on the referring protocol. Use the format expected by the receiving system rather than deleting = indiscriminately.
References
More Base64 guides
Base64 padding explained: what = and == mean
Understand Base64 padding with f, fo and foo examples. Check missing padding, invalid lengths and why deleting = is not always safe.
JavaScript Base64 with Unicode: fix btoa() errors using UTF-8
Encode and decode Korean, Hindi and emoji in JavaScript with TextEncoder, btoa, atob and TextDecoder. Includes tested Unicode-safe code and browser examples.