Skip to content
100% in your browser. Nothing you paste is uploaded — all processing runs locally. Read more →

Base64url (URL-safe)

Same engine as the main encoder, but URL-safe by default. - and _ instead of + and /.

🔒 100% client-side · no upload · no account

The two characters that change

Standard base64Base64url
Position 62+-
Position 63/_
PaddingRequired =Optional =

The 62 alphanumeric characters at positions 0–61 are identical in both variants. Only the last two and the padding rule differ.

Where base64url is used

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 §5 says it's optional for the URL-safe variant — and JWT explicitly requires it omitted. Other systems may insist on it.

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

Common pitfalls

FAQ

What makes base64url 'URL-safe'?

Standard base64 uses + and /, both reserved in URL syntax — + means 'space' in query strings, / is a path separator. Base64url replaces them with - and _ respectively, so the encoded value can sit in a URL without further encoding.

Is padding still used?

RFC 4648 §5 says padding is optional for base64url. Most JWT implementations omit it; some other systems require it. Tick 'Strip padding' to omit; leave it on to keep = at the end.

Can I encode a JWT with this?

You can encode parts of a JWT (header, payload). For full JWT signing/verifying, use our JWT decoder instead.