Base64 / URL / hex

What are these encodings?

Base64, URL (percent) encoding, and hexadecimal are three ways to represent arbitrary bytes as plain text. They exist because many protocols — email, JSON, URLs, HTTP headers — were designed for ASCII and reject or corrupt raw binary. Encoding makes binary safe to ship through these channels at the cost of size: Base64 inflates input by about 33 percent, hex by 100 percent, and percent-encoding by a variable amount depending on how many bytes need escaping.

Base64 is defined in RFC 4648, percent encoding in RFC 3986, and hex is the conventional 2-character-per-byte representation used everywhere from checksums to CSS colors.

How it works

Standard Base64 maps every 3 input bytes to 4 output characters from the 64-character alphabet A-Z a-z 0-9 + /, padding short inputs with =. Base64URL (also RFC 4648) substitutes - for + and _ for / and drops padding entirely — this is the variant used in JWTs and other URL-bearing contexts.

Percent encoding represents a byte as % followed by two hex digits. Bytes outside the unreserved set (ASCII letters, digits, -, ., _, ~) get escaped. Hex is the simplest of the three: each byte becomes two characters from 0-9 a-f, with case being a stylistic choice — lowercase is conventional but tools differ.

When to use this tool

• Embedding binary data — images, certificates, signatures — in a text-only protocol such as email (MIME) or JSON.
• Decoding a JWT segment by hand to verify the header or payload (use Base64URL mode for these).
• Building or decoding data: URIs such as data:image/png;base64,....
• Constructing or sanitizing URL query parameters that contain spaces, plus signs, or non-ASCII characters.
• Comparing the hex output of a checksum or hash against another tool when only the bytes matter.

Common pitfalls

• Standard Base64 and Base64URL are not interchangeable. A JWT segment contains - and _, which are not valid standard Base64. Use the URL variant or convert before decoding.
• UTF-8 versus byte input. Encoding the string “café” requires first encoding it to UTF-8 bytes (63 61 66 c3 a9), then Base64-encoding those bytes. Skipping the UTF-8 step on non-ASCII text produces silently wrong output.
• Double-encoding URLs. Calling encodeURIComponent twice gives %2520 in place of a space. The receiving server will decode once and see %20 as literal characters.
• Hex case mismatches. SHA-256 hex from one tool may be uppercase and another lowercase — the bytes are identical, but a string equality check will fail.
• Encoding is not encryption. Anyone can decode Base64 instantly. Treat encoded payloads as plaintext for security purposes.

Frequently asked

What is the difference between Base64 and Base64URL?

Standard Base64 uses +, /, and = padding. Base64URL replaces + with -, / with _, and drops the padding so the result is safe to drop into a URL or filename.

Why does my JWT not decode in this tool?

You likely picked Base64 mode rather than Base64URL. JWT segments are encoded with the URL-safe alphabet and have no padding; switching modes almost always fixes it.

How do I encode binary data safely for a URL?

Use Base64URL or percent-encoding. Base64URL is preferable for blobs because the output length is predictable and never expands on already URL-safe input.

Is encoding the same as encryption?

No. Encoding is reversible by anyone — there is no secret involved. Anything you can Base64-encode you can Base64-decode without a key.