Base64URL encoder and decoder — URL-safe Base64 for tokens and links

Encode text into URL-safe Base64, which uses - and _ instead of + and / and usually drops the = padding, or decode a Base64URL value such as a JWT segment back into text.

Live demo · real result from this tool
Direction

Encoded

dXNlcj1hc2hhJnNjb3BlPXJlYWQrd3JpdGU_4pyT

Processed on your device — nothing is uploaded.

How to use the Base64URL tool

  1. Set Direction to Encode or Decode.
  2. Paste your text or Base64URL value into Input.
  3. When encoding, tick Keep = padding only if the receiving system asks for it.
  4. Copy the Encoded or Decoded result.

What it does and when to use it

Base64URL is the variant of Base64 made for places where +, / and = cause trouble: query strings, path segments, cookie values and file names. Its best-known use is in JSON Web Tokens, where the header, payload and signature are each Base64URL-encoded and joined with dots. You will also see it in OAuth PKCE values, WebAuthn data and short links built from random bytes.

Use the encoder to build a test token segment or a URL-safe ID from text. Use the decoder to look inside a token segment or a value copied from a URL.

To read a whole token with its claims and expiry time in one go, the JWT decoder is easier. For standard Base64 with line-length options, use the Base64 encoder. If you need the raw bytes of a value as hex, the Base64 to hex converter accepts URL-safe input too.

How it works

The tool follows RFC 4648, section 5, “Base 64 Encoding with URL and Filename Safe Alphabet”.

  1. Text is converted to UTF-8 bytes.
  2. Every 3 bytes (24 bits) are split into four 6-bit values.
  3. Each value picks a character from A–Z a–z 0–9 - _.
  4. A final group of 1 or 2 bytes gives 2 or 3 characters; with padding on, = signs fill it to 4.

The decoder first maps - and _ to + and /, strips whitespace and padding, checks every character, and then reverses the steps. It names the position of any invalid character. All of this runs in your browser.

Worked examples

<<???>>                          →  PDw_Pz8-Pg
<<???>>  (Keep = padding)        →  PDw_Pz8-Pg==
{"alg":"HS256","typ":"JWT"}      →  eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
PDw/Pz8+Pg==  (Decode)           →  <<???>>

The first input was chosen because its standard Base64 contains both / and +; here they appear as _ and -. The third line is the familiar first segment of many JWTs. The last shows the decoder reading standard Base64 without complaint.

Limits and tips

  • Encoding always treats the input as text. It cannot encode raw bytes typed as hex.
  • If a decoded value looks like JSON, paste it into a JSON formatter to read it comfortably.
  • Base64URL is not a secret. Do not put passwords or personal data in a token just because it looks scrambled.

Frequently asked questions

What is the difference between Base64 and Base64URL?
Only two characters and the padding. Standard Base64 uses + and /, which have meanings in URLs and file paths. Base64URL uses - and _ instead, and padding is usually left off. The bytes underneath are the same.
Can the decoder read normal Base64 too?
Yes. It accepts both alphabets, even mixed in one string, with or without = padding, and ignores spaces and line breaks. So PDw/Pz8+Pg== and PDw_Pz8-Pg both decode to the same text.
Why is padding off by default?
Most uses of Base64URL, including JSON Web Tokens, leave the = signs out because = also has a meaning in URLs. Tick "Keep = padding" if the system you are sending to wants it.
Is a JWT encrypted because it looks like random text?
No. A normal JWT's header and payload are only Base64URL-encoded JSON. Anyone can decode them, which is why secrets should never be placed in a token payload.
Why do I see hex instead of text after decoding?
The decoded bytes are not valid UTF-8 text, which is normal for signatures, hashes and random IDs. The tool shows them as hex so nothing is lost.

Sources

  1. RFC 4648: The Base16, Base32, and Base64 Data Encodings (section 5) — IETF / RFC Editor, accessed 2026-10-08
  2. RFC 7515: JSON Web Signature (JWS) — IETF / RFC Editor, accessed 2026-10-08

Written by the ToolsRift team · Last updated

Pages are drafted with AI assistance and checked by automated tests. How we write and check pages.

Was this tool useful?

Report a problem

Start typing to search every tool.

↑ ↓ to moveEnter to openEsc to close