Encoding Basics: Base64, Hex, and URL Encoding Explained

Encoding has nothing to do with secrecy. It's about getting data through systems that only accept certain character sets. If you're building APIs, embedding images in HTML emails, or passing parameters in URLs, picking the right encoding keeps your data intact and saves you from weird bugs. This guide covers the three encodings you'll run into most — Base64, hexadecimal, and URL encoding — and when to use each one.

What is encoding?

Encoding transforms data from one format to another so it survives the trip through a particular channel. That channel might be an email protocol limited to ASCII, a URL bar that chokes on spaces, or a JSON payload that can't carry raw binary. The important thing is that encoding is fully reversible. Anyone with the right decoder can get back the original data — no key or password needed. That's what makes it different from encryption, which exists specifically to keep data secret.

Encoding always adds overhead — more bytes to say the same thing — so pick the smallest encoding that fits your situation. The wrong choice wastes bandwidth, bloats payloads, and can cause subtle bugs when different systems interpret the output their own way.

Base64 encoding

Base64 turns binary data into 64 ASCII characters (A–Z, a–z, 0–9, +, /) plus an optional padding character (=). Every three bytes of input become four characters of output, so you're looking at roughly 33% more data. That trade-off is usually worth it when you need to stuff binary content into text-only environments.

Common use cases for Base64

• Email attachments: MIME encoding uses Base64 to attach images, PDFs, and other files to emails that only support 7-bit ASCII.
• Data URIs: You can embed small images directly in HTML or CSS with data:image/png;base64,... and skip the extra HTTP request.
• API payloads: JSON APIs often Base64-encode binary fields like file uploads or cryptographic signatures so the payload stays valid JSON.
• JWT tokens: JSON Web Tokens use Base64url (a URL-safe variant) for the header and payload segments.

Try it yourself with the Base64 Encoder and Base64 Decoder. If you work with JWTs or URLs, look for Base64url variants that swap + and / for - and _ so you don't run into trouble in query strings.

Hexadecimal encoding

Hexadecimal (hex) represents each byte as two characters using digits 0–9 and letters A–F. That doubles the size of the original data, so it's less compact than Base64. The upside is readability. Every pair of characters maps to exactly one byte, which makes hex great for looking at raw data byte by byte.

Common use cases for hex

• Debugging network packets: Tools like Wireshark show packet payloads in hex so you can inspect individual bytes.
• Hash values: SHA-256 and MD5 hashes are almost always displayed in hex, like e3b0c44298fc1c149afbf4c8....
• Color codes: CSS colors like #1A2B3C are hex representations of RGB values.
• Binary file inspection: Hex editors let you view and edit any file at the byte level.

Use the Hex Encoder when you need to convert text to hex for debugging or when a protocol expects hex-encoded values.

URL encoding (percent encoding)

URLs only allow a specific set of characters, defined by RFC 3986. Anything outside that set — spaces, ampersands, question marks, non-ASCII characters — has to be percent-encoded. That means replacing each unsafe byte with a percent sign followed by two hex digits. A space becomes%20 and an ampersand becomes %26.

When URL encoding is required

• Query parameters: If a search term contains special characters like & or =, it will break parameter parsing unless you encode it first.
• Path segments: File names with spaces or Unicode characters need encoding to produce a valid URL.
• Form submissions: HTML forms using application/x-www-form-urlencoded automatically percent-encode field values.
• Redirect URLs: When you pass a URL as a parameter inside another URL, the inner URL must be fully encoded.

Use URL Encode when sending data in query strings so you don't end up with broken URLs or mangled parameters. Forgetting to encode user-supplied input is one of the most common causes of broken links and security holes in web apps.

Comparing Base64, hex, and URL encoding

Each encoding does a different job. Here's a quick comparison to help you pick:

• Size overhead: Base64 adds about 33%, hex doubles the size, and URL encoding varies depending on how many unsafe characters are in the input.
• Readability: Hex is the easiest to read when you're inspecting individual bytes. Base64 is opaque. URL encoding stays readable as long as the input is mostly ASCII.
• Binary support: Base64 and hex can handle arbitrary binary data. URL encoding is meant for text characters within URLs.
• Reversibility: All three are fully reversible with the right decoder.

Which encoding should I use?

• Use Base64 when you need to embed binary data in text contexts like emails, JSON APIs, or data URIs.
• Use hex for debugging, displaying hashes, or when a protocol specifically calls for hex-encoded values.
• Use URL encoding for query parameters, path segments, and any user input that ends up in a URL.
• If you're not sure, think about where the data is going. URL? Use URL encoding. Text protocol carrying binary? Base64. Need to inspect individual bytes? Hex.

Common mistakes to avoid

• Double encoding: Encoding a string that's already encoded gives you garbled output like %2520 instead of %20. Check whether your framework is already encoding values before you add another layer.
• Confusing encoding with encryption: Encoding provides zero security. Don't use Base64 to "hide" passwords or API keys.
• Using the wrong Base64 variant: Standard Base64 uses + and / which aren't safe in URLs. Use Base64url when encoding data for query strings or JWT tokens.
• Forgetting to decode: Storing encoded data permanently wastes space and makes searching harder. Decode when the data reaches its destination.