Glossary · Definition
Base64 vs Base64URL
Standard Base64 (RFC 4648) uses A-Z, a-z, 0-9, +, /, and = padding. Base64URL replaces + with - and / with _ for URL/filename safety. Same encoding, different alphabets. JWTs, OAuth tokens, and URL parameters use Base64URL; everything else typically uses standard.
Definition
Standard Base64 (RFC 4648) uses A-Z, a-z, 0-9, +, /, and = padding. Base64URL replaces + with - and / with _ for URL/filename safety. Same encoding, different alphabets. JWTs, OAuth tokens, and URL parameters use Base64URL; everything else typically uses standard.
What it means
Why two variants? Standard Base64’s ‘+’ and ‘/’ characters have special meaning in URLs (space and path separator) and filenames (some filesystems disallow). Base64URL substitutes them with characters safe in those contexts. Padding: standard Base64 always pads with ‘=’ to multiple-of-4 length; Base64URL often omits padding (per RFC 7515 for JWTs) since URL queries don’t need it. <strong>Detection</strong>: if the string contains <code>+</code> or <code>/</code>, it’s standard Base64. If <code>-</code> or <code>_</code>, it’s Base64URL. Conversion: replace pairs to switch between variants. Most modern Base64 libraries support both.
Advertisement
Formula
Base64URL = Base64 with + → - and / → _, optional padding removal
Why it matters
Mixing variants causes silent decoding failures. JWT tokens use Base64URL throughout (header, payload, signature). Decoding a JWT with standard Base64 fails on the first <code>-</code> or <code>_</code> character. OAuth 2.0 PKCE codes use Base64URL. Data URIs (data:image/png;base64,...) use standard Base64. Cookies typically use Base64URL since cookies travel in HTTP headers. Knowing which variant your data uses prevents decoding errors.
Example
Standard: <code>SGVsbG8sIFdvcmxkIQ==</code>. Base64URL: <code>SGVsbG8sIFdvcmxkIQ</code> (= padding optional). With special chars, ‘+/+’ in standard becomes ‘-_-’ in URL variant.
Related free tools
Frequently asked questions
Does removing padding lose information?
No. Padding (=) is purely formatting to make output length a multiple of 4. The actual encoded data is identical. Decoders auto-handle missing padding by inferring from length.
Can I use Base64URL where standard is expected?
Often no. Some standard Base64 decoders reject - and _ characters. JWTs are designed for Base64URL; standard Base64 decoders fail on JWT tokens.
What’s Base32 / Base58?
Base32: 32-character alphabet (e.g., RFC 4648 Base32 uses A-Z + 2-7), used in some QR codes and DNS. Base58: removes look-alikes (0/O, 1/I/l), used in Bitcoin addresses. Different use cases; same encoding-via-alphabet idea.
Related terms
- DefinitionData URI imagesData URIs encode binary files (images, icons) as base64 strings inside URLs: <code>data:image/png;base64,...</code>. Saves an HTTP request but inflates file size 33% and loses browser caching. Best for tiny critical-path icons (under 5KB); avoid for larger images.
- DefinitionJWT token structureA JWT is three Base64URL-encoded JSON objects separated by dots: header.payload.signature. Header declares signing algorithm; payload contains claims; signature verifies authenticity. JWTs are NOT encrypted by default — anyone can decode the payload to read it. Use JWE for encryption.