How does URL-safe Base64 differ from standard Base64?

The encoded data is identical except for two characters. Standard Base64 uses + and /, both of which have special meaning in URLs and file paths. URL-safe Base64 (RFC 4648 §5, also called base64url) substitutes - for + and _ for /, so the string needs no percent-encoding.

Why is padding often removed?

The trailing = characters are only there to make the length a multiple of four. In URLs an = can be ambiguous or need escaping, so base64url commonly drops it. The length still implies how many bytes the final group holds, so a correct decoder recovers the data without padding.

Is this the encoding used by JWTs?

Yes. JSON Web Tokens encode their header, payload and signature with base64url and no padding, joined by dots. You can paste a single JWT segment here to decode it, or encode a JSON payload into the base64url form a JWT expects.

Will it decode standard Base64 too?

Yes. The decoder normalizes - back to + and _ back to /, strips whitespace, and tolerates missing or present padding, so it accepts both the standard and URL-safe alphabets without you choosing which one you have.

What is the URL-Safe Base64 Encoder/Decoder?

Free URL-safe Base64 encoder and decoder per RFC 4648 §5. Replaces + with - and / with _, optionally drops = padding, and decodes both standard and URL-safe input. Safe for URLs, JWTs, query strings and file names. Client-side. It runs free in your browser on Gera Tools, with nothing uploaded.

URL-Safe Base64 Encoder/Decoder

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

URL-safe Base64 is the variant of Base64 you reach for when the encoded value has to live inside a URL, query string, file name or token without breaking anything. This tool encodes UTF-8 text to URL-safe Base64 and decodes it back, following RFC 4648 §5, all in your browser.

Why the standard Base64 alphabet breaks in URLs

Standard Base64 uses a 64-character alphabet: A–Z, a–z, 0–9, +, /, padded with =. Three of those characters cause problems outside of file contexts:

+ is decoded as a space by application/x-www-form-urlencoded parsers, turning binary data into garbled results.
/ is a URL path separator; an encoded value containing / can be misinterpreted as a path segment.
= is used as a key-value separator in some query strings and needs percent-encoding in URLs.

URL-safe Base64 (RFC 4648 §5, sometimes written base64url) substitutes - for + and _ for /, and typically drops the = padding. The result is a string that can be dropped directly into a URL, file name, or header value without any further encoding.

How it works

The underlying transform is ordinary Base64: input bytes are taken three at a time (24 bits) and split into four 6-bit values, each mapped to a character. The only change for the URL-safe alphabet is the last two symbols. Standard Base64 ends its alphabet with + and /; URL-safe Base64 uses - and _ instead, because + is read as a space and / is a path separator in URLs. The result therefore survives in a link without percent-encoding.

Padding is optional. Standard Base64 pads the final group with = to a multiple of four characters, but base64url normally drops it since the length already implies how many real bytes the last group contains. This tool lets you keep or drop the padding when encoding, and its decoder accepts input with or without it, in either alphabet, after stripping whitespace.

Common use cases

JSON Web Tokens (JWTs) are the most widespread use of base64url. A JWT has the form header.payload.signature, where each segment is base64url-encoded with no padding. The header decodes to a JSON object like {"alg":"HS256","typ":"JWT"}, and the payload contains the claims. Paste a single segment into the decode field to inspect it.

OAuth 2.0 / PKCE uses base64url for the code_challenge derived from the code_verifier. The code verifier is a random string, hashed with SHA-256, and the result is base64url-encoded for the authorization request.

URL-safe identifiers — many systems generate random tokens (password reset links, invite codes, API keys) and encode them as base64url to keep the string compact while remaining URL-safe.

Cookie values and HTTP headers — base64url avoids the space and special-character restrictions that affect these contexts when binary data needs to be transmitted.

Tips and notes

If a downstream system rejects your value, check whether it expects padding (= at the end). Some JWT libraries require no padding; others require it. The decoder here accepts both. Remember that base64url is a reversible encoding, not encryption — anyone with the string can decode it, so never put secrets in a base64url value and assume they are hidden.

All encoding and decoding, including UTF-8 handling, run entirely in your browser. Nothing is uploaded.