Base64url (URL-safe)

Encode and decode Base64URL, the URL-safe Base64 variant defined in RFC 4648 §5, right in your browser. It swaps + and / for - and _ so the result can sit in a URL or filename, and the Strip padding option drops the trailing = the way JWTs do. Nothing is uploaded and no account is needed.

The two characters that change

The 62 alphanumeric characters at positions 0–61 are identical in both variants. RFC 4648 changes only the last two alphabet characters.

Padding is not part of the difference. RFC 4648 §3.2 sets one padding rule for both alphabets, covered below.

Where base64url is used

• JWT (JSON Web Tokens). All three parts of every signed JWT (JWS) are base64url-encoded, and RFC 7515 §2 says to omit the padding. Encrypted JWTs (JWE) have five dot-separated parts (header, encrypted key, IV, ciphertext, tag), and those are base64url too. This page keeps the trailing = unless you tick 'Strip padding (=)'.
• URL query parameters. Embedding base64 in ?token=... requires URL-safe encoding to avoid double-encoding.
• Cookie values. Cookies allow more characters than URL paths, but base64url avoids any escaping concerns.
• Filenames. Most filesystems accept - and _ but reject /. Standard base64 in a filename breaks anywhere with hierarchical paths.
• Database keys. Some systems use base64url-encoded UUIDs as compact, URL-safe primary key external IDs.

Translating between variants

Two-line conversion in any language:

// Standard → URL-safe
b64.replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");

// URL-safe → Standard
b64url.replace(/-/g, "+").replace(/_/g, "/") + "=".repeat((4 - b64url.length % 4) % 4);

The bytes encoded are identical; only the surface alphabet differs. A decoder that handles both should normalize URL-safe to standard before calling atob().

Padding: keep it or strip it?

Padding (=) makes the length a multiple of 4. RFC 4648 §3.2 says implementations must include that padding unless the referring specification says otherwise. §5 only notes that = may be skipped when the data length is known implicitly. For signed JWTs (JWS), RFC 7515 is the spec that says to omit the trailing =. Other systems may insist on it.

The 'Strip padding (=)' box on this page starts unticked, so the default output keeps the =. Tick it when you want the unpadded form a signed JWT uses.

Convention: strip for JWT and URLs, keep for everything else unless told otherwise. Most decoders accept both.

Common pitfalls

• Mixing variants in one pipeline. If you encode standard but decode URL-safe (or vice versa) without normalizing, the value won't roundtrip.
• URL-encoding base64url. - and _ are unreserved URL characters, so a standards-compliant URL encoder (such as encodeURIComponent) leaves them alone. It does not turn - into %2D. If a downstream tool URL-encodes the string anyway, the only character that gets escaped is the padding =, as %3D. Strip the padding first if that escaping is a problem, or skip the extra URL-encoding step.
• Padding length on URL-safe input. atob in current browsers accepts input without padding but rejects - and _, so swap those back to + and / first. Stricter decoders in other languages may need the padding: add = until the length is a multiple of 4.