Base64URL Encoder & Decoder — Encode, Decode, Convert

Encode and decode URL-safe Base64 strings used in JWTs, PKCE, and WebAuthn

Base64URL Encode/Decode

Characters: 0 Bytes: 0
Characters: 0

Base64 vs Base64URL

Base64URL is a URL-safe variant of Base64 encoding. It replaces characters that have special meaning in URLs:

Character Standard Base64 Base64URL Why Changed
62nd char + - (hyphen) + becomes space in URLs
63rd char / _ (underscore) / is a path separator
Padding = Optional (often omitted) = has meaning in query strings

Common Uses for Base64URL

  • JWT Tokens — The header and payload sections of a JSON Web Token are Base64URL-encoded JSON objects, concatenated with dots
  • OAuth / PKCE — The code verifier is a random string and the code challenge is its SHA-256 hash, Base64URL-encoded without padding (RFC 7636)
  • WebAuthn / FIDO2 — Credential IDs, authenticator data, and signatures are exchanged as Base64URL strings between browser and server
  • URL Parameters — Safe to embed in query strings without additional percent-encoding
  • Filenames — Contains only characters allowed by all major file systems (no / or +)

Worked Examples

Example 1 — Simple text

Encoding the string Hello, World!:

FormatResult
Standard Base64SGVsbG8sIFdvcmxkIQ==
Base64URL (with padding)SGVsbG8sIFdvcmxkIQ==
Base64URL (no padding)SGVsbG8sIFdvcmxkIQ

This input has no + or / in its Base64 output, so the only difference is the removed padding.

Example 2 — Characters that differ

Encoding the bytes [0xFB, 0xFF, 0xFE] (hex: fbfffe):

FormatResult
Standard Base64u//+
Base64URLu__-

Here you can see the actual character replacements: /_ and +-.

Example 3 — JWT header

A typical JWT header {"alg":"HS256","typ":"JWT"} encodes to:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Paste this into the input above and click Decode from Base64URL to see the original JSON.

How Base64URL Encoding Works

Base64URL is a URL-safe variant of Base64 encoding defined in RFC 4648 §5. It converts arbitrary binary data into a string of ASCII characters that can be safely used in URLs, filenames, and HTTP headers.

Step-by-step process

  1. Convert the input to bytes (using UTF-8 for text)
  2. Encode the bytes with the standard Base64 algorithm (groups of 3 bytes → 4 characters)
  3. Replace every + with - (hyphen)
  4. Replace every / with _ (underscore)
  5. Optionally remove trailing = padding characters

Why the character substitutions matter

  • + is interpreted as a space in URL query strings (application/x-www-form-urlencoded)
  • / is the path separator in URLs, so it would break path-based routing
  • = separates keys from values in query strings (?key=value)

By replacing these three characters, Base64URL output can be embedded directly in URLs without additional encoding.

Padding: to include or omit?

Standard Base64 pads output to a multiple of 4 characters using =. Base64URL allows omitting padding because the decoder can calculate how many padding characters are missing from the string length:

  • Length mod 4 = 0 → no padding needed
  • Length mod 4 = 2 → add ==
  • Length mod 4 = 3 → add =
  • Length mod 4 = 1 → invalid input

JWTs, PKCE, and most modern specs omit padding. Some older APIs may still expect it — check your spec.

Frequently Asked Questions

What is Base64URL encoding?

Base64URL is a variant of Base64 that replaces + with - and / with _ so the output is safe to use in URLs and filenames. Padding (=) is usually omitted. It is defined in RFC 4648 §5.

What is the difference between Base64 and Base64URL?

Standard Base64 uses + and / as its 62nd and 63rd characters and requires = padding. Base64URL replaces + with - (hyphen) and / with _ (underscore), and typically omits padding. This makes the output safe for URLs, query strings, and filenames without percent-encoding.

Why do JWTs use Base64URL instead of Base64?

JWTs are transmitted in HTTP headers (Authorization: Bearer …) and sometimes in URL query parameters. Standard Base64 characters + and / have special meanings in URLs — + becomes a space and / is a path separator. Base64URL avoids these conflicts, so JWT strings can be used directly without extra encoding.

Should I include padding in Base64URL?

It depends on the specification you're implementing:

  • JWTs (RFC 7515) — no padding
  • PKCE code challenge (RFC 7636) — no padding
  • WebAuthn — no padding
  • Some legacy APIs — may expect padding

When in doubt, omit padding. Most modern decoders handle both.

Is Base64URL encoding the same as URL encoding (percent-encoding)?

No. URL encoding (percent-encoding) replaces unsafe characters with %XX sequences — for example, a space becomes %20. Base64URL is a binary-to-text encoding scheme that produces only URL-safe characters (A-Z, a-z, 0-9, -, _). They solve different problems and are not interchangeable.

Is Base64URL encryption?

No. Base64URL is encoding, not encryption. Anyone can decode a Base64URL string without a key. Never use it to protect sensitive data. Use proper encryption (AES, ChaCha20, etc.) for security.

How do I decode a JWT payload?

A JWT has three dot-separated parts: header.payload.signature. Copy the middle part (payload), paste it into the input above, and click Decode from Base64URL. The result is the raw JSON with claims like sub, exp, and iat. You can also use our JWT Decoder to parse all three parts at once.

What happens if my Base64URL string has the wrong length?

Valid Base64URL strings have a length that, after adding padding, is divisible by 4. If length mod 4 = 1, the string is invalid and cannot be decoded. Other lengths (mod 4 = 0, 2, or 3) are valid — the decoder adds the missing padding automatically.

Can I convert standard Base64 to Base64URL?

Yes. Replace + with -, replace / with _, and optionally strip trailing =. Use the Convert from Standard Base64 button above to do this automatically.

What is a PKCE code challenge?

In OAuth 2.0 with PKCE (RFC 7636), the client generates a random code_verifier, then computes code_challenge = BASE64URL(SHA256(code_verifier)) — without padding. The authorization server uses this to verify the client's identity without a client secret.

Does this tool send my data to a server?

No. All encoding and decoding happens entirely in your browser using JavaScript. No data is transmitted. You can verify this by disconnecting from the internet and using the tool offline.

Related Tools

Privacy & Limitations

  • All calculations run entirely in your browser -- nothing is sent to any server.
  • Results are computed locally and should be verified for critical applications.

Related Tools

View all tools

Base64URL Encoder/Decoder FAQ

What is Base64URL encoding?

Base64URL is a variant of Base64 that replaces + with - and / with _ so the output is safe to use in URLs and filenames. Padding (=) is usually omitted. It is defined in RFC 4648 §5.

What is the difference between Base64 and Base64URL?

Standard Base64 uses + and / as its 62nd and 63rd characters and requires = padding. Base64URL replaces + with - (hyphen) and / with _ (underscore), and typically omits padding. This makes the output safe for URLs, query strings, and filenames.

Why do JWTs use Base64URL instead of Base64?

JWTs are often transmitted in HTTP headers and URL query parameters. Standard Base64 characters + and / have special meanings in URLs (+ becomes a space, / is a path separator), so JWTs use Base64URL to avoid encoding issues during transport.

Should I include padding in Base64URL?

It depends on the specification. JWTs (RFC 7515) require no padding. OAuth PKCE (RFC 7636) requires no padding. Some APIs expect padding. When in doubt, omit padding — most Base64URL decoders can reconstruct it from the string length.

Is Base64URL encoding the same as URL encoding (percent-encoding)?

No. URL encoding (percent-encoding) replaces unsafe characters with %XX sequences (e.g. space → %20). Base64URL is a binary-to-text encoding that produces only URL-safe characters (A-Z, a-z, 0-9, -, _). They solve different problems.

Is Base64URL encryption?

No. Base64URL is encoding, not encryption. Anyone can decode a Base64URL string without a key. Never use Base64URL to protect sensitive data. Use proper encryption (e.g. AES) for security.

Request a New Tool
Improve This Tool