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, because no secret is involved. Anything you can Base64-encode you can Base64-decode without a key.