URL-safe Base64 vs standard Base64: why your JWT tokens need the variant

Standard Base64 uses + and / in its 64-character alphabet. Those characters have special meaning in URLs (+ is a space in query strings, / is a path separator), so putting standard Base64 in a URL requires percent-encoding. URL-safe Base64 (RFC 4648 §5) replaces + with - and / with _, making the output safe to drop directly into a URL path or query string without any encoding.

Encoding focus
URL-safe Base64
url-safe-base64
Category
Best Practices
Practical encoding guidance

How this is calculated

JWT tokens use URL-safe Base64 for all three segments (header, payload, signature). Without it, every JWT would need to be percent-encoded before appearing in an Authorization: Bearer header or a query parameter. URL-safe Base64 also commonly omits the = padding characters, since the encoded length can be inferred from the string length. JavaScript's btoa() produces standard Base64. To get URL-safe, replace + with -, / with _, and strip trailing =. Most JWT libraries handle this automatically, but if you're hand-rolling token generation, this is the most common mistake.

Verdict

Use URL-safe Base64 for anything that appears in a URL: JWT tokens, OAuth state parameters, verification tokens in emails, and data URIs embedded in SVG. Standard Base64 is for everything else: JSON payloads, MIME attachments, and storage.

More Encoding scenarios

Frequently asked questions

How do I convert text to Base64?
Paste your string into the Text field and the Base64 output appears instantly. The tool uses standard Base64 (RFC 4648), so the output is identical to Linux's base64 command and every major language's built-in Base64 encoder.
What's the difference between Base64 and hex encoding?
Both represent binary data as text, but with different alphabets. Base64 uses 64 characters and needs roughly 4 chars per 3 bytes (33% overhead). Hex uses 16 characters and needs exactly 2 chars per byte (100% overhead). Base64 is denser, while hex is easier to read byte by byte.
Why does my UTF-8 text break when converted to binary?
UTF-8 encodes non-ASCII characters as multibyte sequences, so a single emoji or accented letter becomes 2-4 bytes. The binary output will be longer than the character count suggests, that's correct behavior, not a bug.
Is it safe to paste sensitive data into the converter?
Yes. The encoding conversion runs entirely in your browser with JavaScript, nothing is sent to our servers, logged, or stored. You can verify this with your browser's Network tab: no requests fire when you type.
What is URL-safe Base64?
A variant that replaces `+` with `-` and `/` with `_` so the result can be safely placed in URLs without percent-encoding. JWT tokens use URL-safe Base64. Standard Base64 is fine for most other uses.
Can I decode Base64 back to the original text?
Yes, the converter is bidirectional. Paste Base64 into the Base64 field and you'll get the original UTF-8 string back. If decoding fails silently, the input isn't valid Base64 (wrong characters, bad padding, or it was double-encoded).