Skip to content

URL Safe Base64 Encoder / Decoder

Encode and decode Base64 using the URL-safe alphabet (RFC 4648 §5) — replaces + with - and / with _ so output is safe in URLs, filenames, and JWTs without percent-encoding.

Updated

What is the URL Safe Base64 Encoder / Decoder?

URL-safe Base64 is a variant of the Base64 encoding standard designed to produce output that can be embedded directly in URLs, filenames, HTTP headers, and JSON Web Tokens — without any percent-encoding. It is defined in RFC 4648 §5 and is the encoding format behind JWTs, OAuth tokens, and many modern web APIs.

Standard Base64 uses three characters that carry special meaning in URLs and file systems: +, /, and =. When these appear in a query string or path segment, they must be percent-encoded (%2B, %2F, %3D), which bloats the output and can cause subtle bugs when tokens are copied or logged. URL-safe Base64 solves this cleanly by substituting + → - and / → _, and making the = padding optional.

Use this tool to:

  • Encode any UTF-8 text, JSON payload, or binary data as URL-safe (or standard) Base64
  • Decode Base64url tokens, JWT segments, and encoded query parameters back to plain text
  • Compare the standard and URL-safe variants side by side and see exactly which character substitutions are made
  • Control padding — include or omit the trailing = characters depending on your target system

How it works

Standard Base64 encodes binary data using 64 printable ASCII characters: A–Z, a–z, 0–9, +, and /, plus = for padding. Every 3 bytes of input become 4 Base64 characters, giving a consistent ~33% size overhead.

The URL-Safe Substitution (RFC 4648 §5)

URL-safe Base64 (also called Base64url) makes exactly two character substitutions:

Standard URL-safe Reason
+ - + means space in query strings
/ _ / is the path separator in URLs
= (padding) (omitted) = requires percent-encoding in some contexts

The encoding and decoding process is otherwise identical to standard Base64. No bits are changed — only the alphabet used to represent them.

Encoding Step by Step

  1. UTF-8 encode the input text into raw bytes.
  2. Group bytes into triplets. Each 3-byte group maps to four 6-bit values (0–63).
  3. Map each 6-bit value to the URL-safe alphabet character at that index.
  4. Pad with = if the byte count is not a multiple of 3 — or omit padding if the target system allows it.

For example, the two-character input "Hi" (2 bytes) produces three Base64 characters plus one = pad: "SGk=". Without padding: "SGk".

Decoding Step by Step

  1. Normalise the input: replace - → + and _ → / to get standard Base64.
  2. Re-add padding if missing: append = until the length is a multiple of 4.
  3. Decode with standard Base64 decoding (4 characters → 3 bytes).
  4. UTF-8 decode the resulting bytes back into text.

Padding Rules

= padding ensures the encoded string length is always a multiple of 4. Most modern systems — including the JWT spec (RFC 7519) — work fine without it because the decoder can infer the padding from the string length. This tool lets you choose:

  • Include = — maximum compatibility with legacy or strict parsers.
  • Omit = — cleaner output for URLs, JWTs, and filename-safe tokens (the default for most modern APIs).

When to Use URL-Safe Base64

  • JWTs (JSON Web Tokens): all three segments (header, payload, signature) are Base64url-encoded.
  • OAuth 2.0 / PKCE: the code_verifier and code_challenge use Base64url.
  • URL query parameters: embed binary data in a ?token=… parameter without percent-encoding.
  • Filenames and paths: use encoded data as a file or directory name safely on any OS.
  • HTTP cookies: cookie values cannot contain + or / unescaped in some implementations.

Examples

Encode plain text

Encoding a simple greeting as URL-safe Base64 (padding omitted).

Hello, World!
SGVsbG8sIFdvcmxkIQ

Encode a URL string

A URL containing slashes and query parameters encodes without any percent-encoding issues — the / in the path is replaced with _.

https://example.com/a/b?q=x+y
aHR0cHM6Ly9leGFtcGxlLmNvbS9hL2I_cT14K3k

Encode a JSON payload (JWT-style)

JSON objects are commonly Base64url-encoded as JWT header and payload segments.

{"id":1,"role":"admin"}
eyJpZCI6MSwicm9sZSI6ImFkbWluIn0

Decode a Base64url token

Decode the payload segment from a JWT or similar token back to readable JSON.

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIn0
{"sub":"1234567890","name":"John Doe"}

Standard vs URL-safe comparison

See how standard Base64 characters that are unsafe in URLs are substituted: + becomes - and / becomes _.

https://example.com/~/b?q=x+y
aHR0cHM6Ly9leGFtcGxlLmNvbS9-L2I_cT14K3k

Frequently asked questions

What is the difference between URL-safe Base64 and standard Base64?

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.

Why does my Base64 string end with = or ==?

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.

Can I decode a standard Base64 string with the URL-safe setting?

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.

What is Base64url and is it the same as URL-safe 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.

How are JWTs related to URL-safe Base64?

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.

Does URL-safe Base64 compress my data?

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.

Is URL-safe Base64 the same as URL encoding (percent-encoding)?

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.

Can this tool handle Unicode, emoji, and non-ASCII text?

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.

Should I include or omit the = padding?

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.

What happens if I decode binary data (non-text bytes)?

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.

Why does standard Base64 use + and / if they cause problems in URLs?

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.

Related tools

More utilities you might find handy.

Encoding

Base32 Encoder Decoder

Encode text or hex to Base32 (RFC 4648) and decode Base32 strings back to UTF-8 instantly in your browser.
Encoding

Punycode Converter

Convert internationalized domain names (IDN) to Punycode and vice versa.
Encoding

Quoted-Printable Encoder

Encode and decode MIME quoted-printable text in your browser.