URL Safe Base64 Encoder / Decoder

Standard Base64 uses +, /, and = in its output alphabet. These characters have special meanings in URLs — + is decoded as a space in query strings, / is a path separator, and = requires percent-encoding in some contexts. URL-safe Base64 (RFC 4648 §5) substitutes + → - and / → _, and makes the = padding optional, so the output can be placed directly in a URL without any percent-encoding.

The = characters are padding. Base64 encodes 3 bytes at a time into 4 characters. When the input length is not a multiple of 3, one or two = characters are appended so the total length is always a multiple of 4. One = means the last group had 2 bytes; two == means it had 1 byte. Many modern systems — including JWTs — omit padding entirely, since the decoder can infer it from the string length.

Yes. If your input only contains standard characters (+, /), this tool will decode it correctly regardless of the variant setting. The tool auto-detects which alphabet was used and normalises accordingly. If the input mixes both URL-safe (-, _) and standard (+, /) characters, the tool will report an error because that combination is not valid Base64.

Yes — Base64url is the IETF-standardised name (defined in RFC 4648 §5) for URL-safe Base64. The terms are interchangeable. You will see "Base64url" used in specifications like JWT (RFC 7519), PKCE (RFC 7636), and WebAuthn, while "URL-safe Base64" is the plain-English description of the same encoding.

A JSON Web Token (JWT) consists of three Base64url-encoded segments separated by dots: header.payload.signature. Each segment is encoded using URL-safe Base64 without padding, so the entire token can be safely placed in an HTTP header, a URL query parameter, or a cookie without any escaping. You can decode the header and payload segments of any JWT by pasting them into this tool's Decode mode.

No. Base64 (any variant) increases data size by approximately 33% — every 3 bytes of input become 4 characters of output. It is an encoding, not a compression algorithm. Its purpose is to represent arbitrary binary data using only printable ASCII characters. If you need to reduce data size, compress first (e.g. with gzip or Brotli), then encode.

No, they are entirely different mechanisms. URL encoding (percent-encoding) replaces unsafe characters with %XX hex sequences — for example, a space becomes %20. URL-safe Base64 is a complete binary-to-text encoding that represents raw bytes as a string of letters, digits, hyphens, and underscores. URL-safe Base64 is used when you need to embed arbitrary binary data (like a signature or token) in a URL without the + and / characters that cause problems in query strings.

Yes. The tool uses the browser's built-in TextEncoder (UTF-8) to convert your input text into bytes before encoding, and TextDecoder (UTF-8) to reconstruct text after decoding. This means any character that can be typed or pasted — including CJK characters, Arabic, emoji, accented letters, and symbols — is handled correctly.

It depends on your target system:

• Include = when sending Base64 to legacy systems, email clients, or any API that strictly requires a length that is a multiple of 4.
• Omit = for JWTs, OAuth tokens, URL query parameters, filenames, and any modern API that follows RFC 7515/7516/7517/7519 — these specs explicitly call for unpadded Base64url. When in doubt, try without padding first; most modern decoders accept both forms.

If the decoded bytes are not valid UTF-8, the tool falls back to displaying the raw bytes as uppercase hexadecimal pairs (e.g. FF D8 FF E0 …). This lets you confirm the content type and size even when the data is not human-readable text, such as images, encrypted blobs, or compressed data.

Standard Base64 was designed in the 1980s for email (MIME), long before the web existed. At the time, URL-safety was not a consideration. The + and / characters were chosen simply because they are printable ASCII characters not already used by the alphanumeric alphabet. RFC 4648 introduced the URL-safe variant in 2006 specifically to address the friction that arose once Base64 became widely used on the web.