Base64URL Encoder / Decoder

Base64URL is the URL- and filename-safe flavor of Base64 you see in JSON Web Tokens, OAuth, and anywhere a value rides in a URL. It swaps the troublesome + and / for - and _ and usually drops the = padding. Paste text to encode it, or paste a Base64URL string to decode it back — UTF-8 safe, entirely in your browser.

How to use the Base64URL Encoder / Decoder

Choose Encode to convert text into Base64URL, or Decode to turn a Base64URL string back into text. In encode mode the output uses the URL-safe alphabet (- and _) and omits padding by default; tick Keep = padding if the system you are targeting expects the trailing equals signs.

Decoding is forgiving: it accepts Base64URL with or without padding, and even tolerates standard Base64 with + and /, so you can paste a JWT segment directly. The default example encodes a JWT header object; decode the result and you get the JSON back. Text is treated as UTF-8 in both directions, so accented characters and emoji round-trip correctly.

The conversion is local to your browser — useful when you are inspecting tokens or payloads you would rather not paste into a remote service. Use Copy output to grab the result.

Base64URL versus standard Base64

Base64 encodes binary data as text using 64 printable characters: A–Z, a–z, 0–9, and two symbols. In standard Base64 those two symbols are + and /, and the output is padded to a multiple of four characters with =. That works fine in email and data blobs, but it breaks in URLs: + means a space in query strings, / is a path separator, and = delimits parameters. Putting standard Base64 in a URL therefore requires extra percent-encoding, which is ugly and error-prone.

Base64URL, defined in RFC 4648, fixes this with two substitutions — + becomes - and / becomes _ — and usually drops the = padding entirely. The result is safe to drop into a URL path, a query parameter, a filename, or an HTTP header without any further escaping. The underlying bytes are identical to standard Base64; only those three characters differ, which is why converting between the two is a simple character swap.

This variant is everywhere in modern web auth. A JSON Web Token is three Base64URL strings joined by dots — header, payload, and signature — precisely because tokens travel in URLs and headers. OAuth 2.0 PKCE challenges, WebAuthn data, and many API keys use it for the same reason. When decoding a JWT, remember that Base64URL only obscures the data, it does not encrypt it: anyone can decode the header and payload, so they must never contain secrets. Decoding here lets you inspect those claims safely on your own machine.

Common use cases

  • Inspecting JWTs. Decode the header or payload segment of a token to read its claims without a remote debugger.
  • Building tokens. Encode JSON or binary into a URL-safe string for use in links, parameters, or headers.
  • OAuth and PKCE. Produce or check the Base64URL values used in authorization flows.
  • URL-safe identifiers. Encode data that must survive being placed in a path or filename without escaping.

Frequently asked questions

How is Base64URL different from Base64?
It replaces + with - and / with _, and usually omits the = padding. This makes the output safe to use in URLs, filenames, and headers without extra escaping. The encoded bytes are otherwise identical.

Can I decode a JWT segment here?
Yes. Paste a single segment (the part between dots) in decode mode. The decoder handles missing padding automatically. Note that JWT payloads are only encoded, not encrypted.

Does it handle padding?
Encoding omits padding by default, with an option to keep it. Decoding accepts input with or without padding, so either form works.

Is Base64URL encryption?
No. It is reversible encoding, not encryption — anyone can decode it. Never put secrets in a Base64URL value expecting them to be hidden.