🧩 Base64URL Encoder / Decoder

Base64URL: The Quieter Cousin of Base64 That Powers Modern Auth

If you have ever inspected a JWT (JSON Web Token), clicked an email verification link, or studied an OAuth 2.0 response, you have seen Base64URL in the wild — you just may not have recognized it by name. It looks almost exactly like regular Base64, except it never has a +, never has a /, and most of the time has no trailing = signs either. Those three differences are everything.

Why Regular Base64 Breaks in URLs

Standard Base64 was designed in 1987 for encoding binary data inside email bodies — a world where URLs did not exist as we know them today. Its 64-character alphabet uses A–Z, a–z, 0–9, plus + and /. That was fine for MIME. The problem is that both + and / are reserved characters in URLs. When a browser or HTTP client encounters a + in a query string, it interprets it as a space. A / is treated as a path separator. The padding character = can confuse parsers when it appears inside query parameters.

So if you tried to put a standard Base64 string directly into a URL without percent-encoding it, you would corrupt the data or break the URL structure entirely. You could percent-encode the offending characters (+ becomes %2B, / becomes %2F, = becomes %3D), but then your token balloons in size and becomes ugly in logs and headers. RFC 4648 Section 5 solved this cleanly in 2006 by defining a URL-safe alphabet: swap + for - and / for _, then drop the = padding entirely.

The Three-Character Swap That Changes Everything

The full transformation from standard Base64 to Base64URL is just three substitutions:

• + becomes - (hyphen)
• / becomes _ (underscore)
• = padding is removed (stripped from the end)

Both - and _ are "unreserved" characters in RFC 3986 (the URI standard), meaning they pass through URLs completely unchanged. No percent-encoding needed. The result is a compact, URL-embeddable string that can also safely appear in HTTP headers, cookie values, and filenames.

Decoding reverses the process: replace - with +, replace _ with /, then re-add padding before passing to a standard Base64 decoder. Padding is always computable because Base64 length must be a multiple of 4 — so if the string is 2 characters short, you append ==; if it is 1 character short, you append =. The one invalid case is when the length mod 4 equals 1, which means the input is malformed.

JWTs: Where You Encounter Base64URL Every Day

JSON Web Tokens are the most widespread use of Base64URL in production systems. A JWT has three parts, each Base64URL-encoded and joined by dots: header.payload.signature. The header and payload are JSON objects; the signature is raw binary (HMAC or RSA/ECDSA output). All three are Base64URL-encoded so the entire token is safe to put in an HTTP Authorization header, a cookie, or a URL query parameter.

For example, the header {"alg":"HS256","typ":"JWT"} encodes to eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. Notice no padding — it would need none here. The payload {"sub":"1234567890","name":"John Doe","iat":1516239022} becomes eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ. You can decode either piece in our tool above and read the JSON directly — JWTs are not encrypted by default, just signed.

Unicode and Multibyte Characters

A subtlety that trips up many implementations: JavaScript's native btoa() function only handles Latin-1 characters (code points 0–255). If you pass a string with emoji or Devanagari or Chinese characters directly to btoa(), you get a InvalidCharacterError. The standard workaround is to first UTF-8-encode the string using encodeURIComponent() followed by unescape(), which converts the percent-encoded UTF-8 bytes into a Latin-1-safe representation that btoa() can handle. Decoding does the reverse with atob() then escape() then decodeURIComponent(). Our tool above handles this automatically — you can encode strings in Hindi, Japanese, Arabic, or any other script.

Base64URL vs Base64: When to Use Which

Use standard Base64 when: you are encoding binary attachments in email (MIME), embedding binary data in XML, or working with any system that explicitly expects the +/= alphabet. Use Base64URL when: you are building or consuming JWTs, generating URL-safe tokens for email verification or password reset links, working with the Web Crypto API (which uses Base64URL for key and signature encoding), processing OAuth 2.0 PKCE code verifiers and challenges, or anywhere your Base64 string needs to live inside a URL or HTTP header without modification.

Common Mistakes and How to Avoid Them

The most common bug is forgetting to re-add padding when decoding. Libraries that accept Base64URL input often handle this internally, but if you are writing raw decode logic, always pad back to a multiple of 4 before calling your Base64 decoder. A length that is 0 mod 4 needs no padding, 2 mod 4 needs ==, and 3 mod 4 needs =. Length 1 mod 4 is always invalid — there is no valid Base64URL string of that length.

Another mistake is mixing alphabets mid-flow. If a third-party library hands you a standard Base64 string (containing + and /) and you need to embed it in a URL, always convert it — do not assume the data is already URL-safe just because it is Base64. And in reverse, if you receive a Base64URL string and need to decode it with a standard Base64 library, convert back first.

Finally, watch out for line breaks. Some Base64 encoders insert a newline every 76 characters (per the old PEM and MIME conventions). Base64URL strings should never contain newlines — strip them if you receive data from a legacy system before attempting to decode.

Practical Uses Beyond JWTs

Base64URL shows up in more places than just tokens. The Subresource Integrity (SRI) standard in browsers uses it for hash values in integrity attributes on script and link tags. The Web Authentication API (WebAuthn) and FIDO2 use Base64URL throughout for credential IDs and attestation objects. Google's protobuf-based APIs sometimes use Base64URL for binary fields in JSON representations. URL shortener redirect tokens, signed cookie values, and CSRF tokens are all common places where teams reach for Base64URL to get compact, safe, opaque identifiers.

The tool on this page handles all these scenarios. Paste any Base64URL string to decode it, or enter any text (including JSON payloads) to encode it. The output is always padding-free and uses only the URL-safe alphabet, ready to drop directly into a URL, header, or token without any further escaping.