Base64 / URL Encoder-Decoder

Encode and decode strings using Base64, Base64URL, and URL encoding formats

Result will appear here

Input Length

0 chars

Output Length

0 chars

Size Change

Encoding Formats Explained

Common encoding schemes used in authentication and web development

Base64

Encodes binary data into ASCII using 64 characters (A-Z, a-z, 0-9, +, /). Commonly used in email, data URIs, and API payloads.

Base64URL

URL-safe variant of Base64 that replaces + with - and / with _, and removes padding. Used in JWTs, PKCE, and OAuth2 tokens.

URL Encoding

Replaces unsafe characters with % followed by hex values. Essential for query parameters, form data, and redirect URIs in OAuth2.

Hexadecimal

Represents binary data as hex characters (0-9, a-f). Used for hashes, cryptographic keys, and binary data inspection.

Base64 and base64url in authentication

The two alphabets

Standard base64 uses + and / for the final two characters and pads with =. Base64url replaces those with - and _, and strips the padding, so the result is safe in URLs and HTTP headers without further escaping.

JWTs, PKCE challenges, WebAuthn buffers, and OAuth2 state values all use base64url. Passing one of those to a standard base64 decoder either errors or produces subtly wrong bytes — and it only fails on inputs whose bytes happen to land on those two indices, which makes it maddeningly intermittent.

Encoding is not encryption

Base64 is a transport encoding. It exists so binary data survives channels that expect text. It provides no confidentiality whatsoever — decoding requires no key and is instant.

Anything base64-encoded should be treated as plainly visible. This is why a JWT payload is readable by anyone holding the token, and why putting sensitive data in one is a mistake regardless of how the token was signed.

Padding

Standard base64 pads to a multiple of four characters with =. Base64url omits it, since the length is derivable. Some decoders demand padding and reject unpadded input.

If a decoder rejects a JWT segment, appending = until the length is a multiple of four usually resolves it. Conversely, padding left in a URL context often arrives percent-encoded as %3D, which then needs URL-decoding first.

Frequently asked questions

Two characters and the padding. Base64url uses - and _ where standard base64 uses + and /, and omits the = padding. This makes it safe in URLs and HTTP headers without percent-encoding.

No. It is an encoding with no key and no secrecy. Anyone can decode it instantly. Never rely on it to protect anything.

Usually because it's base64url and you're using a standard base64 decoder, or because the padding was stripped and your decoder requires it. Convert - to + and _ to /, then pad with = until the length is a multiple of four.

No. Encoding and decoding run entirely in your browser.

Base64 represents 3 bytes as 4 characters, so the output is about 33% larger. That overhead is why large payloads in JWTs matter — the token travels on every request.

Base64url shows up everywhere in OAuth2

JWT segments, PKCE challenges, state parameters. AuthAction's SDKs encode and decode all of it correctly so you don't debug padding bugs.

Free, unlimited users. No credit card required.