How is Base64URL different from standard Base64?

Base64URL (RFC 4648 §5) replaces the + and / characters with - and _, and omits the trailing = padding, so the result is safe to use inside URLs and filenames without escaping.

Why does Base64URL drop the = padding?

The = character has special meaning in URLs and form data, so removing it avoids percent-escaping. The decoder restores the correct padding from the string length when reading the value back.

Can it decode JWT segments?

Yes. JWT header and payload segments are Base64URL-encoded, so you can paste a segment into Decode mode to read its raw JSON.

Will standard Base64 decode here too?

Yes. The decoder converts - to + and _ to / and re-adds padding, so it will also accept ordinary Base64 input.

Is Base64URL encryption?

No. It is an encoding, not encryption — anyone can decode it. It only makes binary data safe to transport as text in URLs; it provides no confidentiality.

Why does decoding fail with an invalid length error?

A Base64URL string must not have a length that leaves a single leftover character after padding is restored. That usually means the value was truncated or an extra character crept in.

Is my data uploaded anywhere?

No. Encoding and decoding happen entirely in your browser using the built-in TextEncoder and atob/btoa functions.

What is the Base64 URL-Safe Encoder?

Free Base64URL encoder and decoder. Converts text to the URL-safe Base64 alphabet (- and _ instead of + and /, no padding) used in JWTs and query strings. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Base64 URL-Safe Encoder

Name: Base64 URL-Safe Encoder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Base64URL encoder and decoder

Base64URL is the URL- and filename-safe variant of Base64 defined in RFC 4648 §5. It swaps the two problematic characters — + becomes - and / becomes _ — and drops the trailing = padding, so the encoded string can travel inside a URL query string, a filename or a JWT without any extra percent-escaping.

Why standard Base64 breaks in URLs

Standard Base64 uses three characters that have reserved meaning in URLs:

+ is shorthand for a space in form data (application/x-www-form-urlencoded)
/ is a path separator
= is used as a key-value separator in query strings

If you embed raw Base64 in a URL without escaping, those characters silently corrupt the value on the other side. Percent-encoding them (%2B, %2F, %3D) works but makes the string longer and fragile — many systems double-encode or strip the percent signs. Base64URL sidesteps all of this by design.

How it works

To encode, the tool converts your text to UTF-8 bytes, runs them through the browser’s btoa, then applies three substitutions: + → -, / → _, and it strips trailing =. To decode it reverses those swaps and re-adds the right amount of = padding (so the length becomes a multiple of 4) before calling atob and decoding the bytes as UTF-8.

The padding rule: Base64 groups 3 bytes into 4 characters. If the input length is not a multiple of 3, one or two = signs pad the output. Base64URL removes them — the decoder can recover the correct padding by computing (4 - len % 4) % 4.

Where Base64URL is used

JSON Web Tokens (JWT): The header, payload, and signature segments of a JWT are all Base64URL-encoded and separated by dots. Paste a JWT segment into Decode mode to read its raw JSON. Note that a JWT signature is cryptographic — decoding it reveals the bytes but does not let you forge a new token.

OAuth 2.0 / PKCE: The code verifier and code challenge in the Proof Key for Code Exchange flow are Base64URL strings, because they travel as URL parameters.

URL-safe session and API tokens: Many APIs issue opaque tokens that are internally Base64URL-encoded identifiers or encrypted blobs. Base64URL encoding means the token can go into a cookie, a URL fragment, or an HTTP header without extra escaping.

Content-addressed file IDs: Storage systems sometimes use Base64URL hashes (SHA-256 truncated, for example) as filenames, since / in a standard Base64 hash would be mistaken for a path separator.

Encoding comparison example

A value containing bytes that map to + or / shows the difference clearly:

Input bytes	Standard Base64	Base64URL
`?` `>` `?` `>`	`Pz4/Pg==`	`Pz4_Pg`
`+` `/`	`+/A=`	`-_A`

And a value with no +, /, or = in its Base64 encoding — such as plain ASCII letters — looks identical in both variants.

Everything runs locally in your browser — your data is never uploaded.