Developer Encoding & Decoding: The Essential Reference
Data rarely travels from one system to another in its raw form. Encoding transforms data into a format that can safely pass through a transport layer—an HTTP request, an HTML document, a database field, or a JSON payload. Decoding reverses the process. Knowing which encoding applies in which context is a core skill for any developer, and getting it wrong causes bugs ranging from broken image embeds to authentication failures. This guide covers the encodings you will encounter most often, explains how each one works, and points you to the right tool for each task.
Base64 Encoding and Decoding
Base64 represents arbitrary binary data using only 64 printable ASCII characters (A–Z, a–z, 0–9, +, /). Every 3 bytes of input become 4 Base64 characters, so the encoded output is approximately 33% larger than the input. Base64 is used to embed images in CSS, transmit binary data in JSON, and encode credentials in HTTP Basic Auth headers.
| Input bytes | Base64 output |
|---|---|
Man (3 bytes) | TWFu (4 chars) |
Ma (2 bytes) | TWE= (4 chars with padding) |
M (1 byte) | TQ== (4 chars with double padding) |
Encode any text or binary string with the Base64 Encoder and reverse the process with the Base64 Decoder. Note that Base64 is an encoding, not encryption—anyone can decode it instantly.
URL Encoding (Percent Encoding)
URLs may only contain a restricted set of characters. Any character outside that set—spaces, non-ASCII characters, and reserved characters like &, =, and #—must be percent-encoded as %XX where XX is the hexadecimal byte value. For example, a space becomes %20 and an ampersand becomes %26.
Failing to encode query parameters correctly is a common source of broken links and 400 errors. The URL Encoder handles the full encoding pass, and the URL Decoder makes encoded URLs human-readable again. When debugging a complex query string, converting it to a structured object with the Query String to JSON Converter is often faster than reading raw percent-encoded text.
HTML Entity Encoding
HTML reserves characters like <, >, &, and " for markup. If your content contains these characters, they must be replaced with named or numeric entities to prevent browsers from interpreting them as HTML. For example, < becomes < and & becomes &. Failing to encode user-supplied content before inserting it into an HTML page is the root cause of cross-site scripting (XSS) vulnerabilities. Use the HTML Entity Encoder to safely escape content and the HTML Entity Decoder to convert encoded text back to readable form.
JWT Payload Decoding
A JSON Web Token (JWT) consists of three Base64URL-encoded sections separated by dots: header.payload.signature. The payload carries claims such as the user ID, expiry time (exp), issued-at time (iat), and any custom application claims. Decoding the payload requires Base64URL decoding (which uses - and _ instead of + and /), not standard Base64. The JWT Payload Decoder handles the URL-safe variant automatically and displays the header and payload as pretty-printed JSON. Remember: decoding a JWT does not verify its signature—always validate signatures server-side.
JSON: Validation and Minification
JSON (JavaScript Object Notation) is the de facto data interchange format for APIs. Two of the most common JSON workflows in development are:
- Validation: Before consuming a JSON response programmatically, confirm it is syntactically valid. Common errors include trailing commas, unquoted keys, and single-quoted strings. The JSON Validator highlights the exact line and position of any syntax error.
- Minification: Removing whitespace and line breaks from a JSON file reduces its byte size—useful before embedding it in a script tag or sending it over a bandwidth-constrained connection. The JSON Minifier strips all non-significant whitespace in one click.
Unix Epoch Timestamps
The Unix epoch is the number of seconds (or milliseconds in many languages) elapsed since 1 January 1970 00:00:00 UTC. It is timezone-agnostic, making it the standard format for storing and transmitting dates in databases and APIs. Common timestamp operations:
| Task | Tool |
|---|---|
| Convert a Unix timestamp to a readable date | Unix Epoch to Date Converter |
| Convert a calendar date to a Unix timestamp | Date to Unix Epoch Converter |
When debugging API responses, timestamps like 1735689600 are meaningless at a glance. Pasting them into the Unix Epoch to Date Converter immediately reveals the human-readable date and time.
Byte Length and Size Calculations
In UTF-8 encoding (the web standard), not every character is 1 byte. ASCII characters (code points 0–127) are 1 byte each, but characters outside that range use 2–4 bytes. This matters when enforcing database column limits, calculating HTTP Content-Length headers, or validating SMS message lengths. The String Byte Length Calculator gives you the exact byte count for any input string in UTF-8. To convert raw byte counts into human-readable sizes like “1.4 MB” or “892 KB,” use the Bytes to Human Readable Converter.
Common Mistakes to Avoid
- Double-encoding URLs: Encoding an already-encoded URL produces
%2520(the percent sign itself gets encoded). Always decode first if the input might already be encoded. - Confusing Base64 with encryption: Base64 is trivially reversible. Never use it to “hide” sensitive data without additional encryption.
- Trusting JWT payloads without signature verification: A decoded payload shows the claims but gives no guarantee they have not been tampered with. Always verify the signature on the server.
- Assuming 1 character = 1 byte: This is only true for ASCII. Multi-byte characters in UTF-8 will cause off-by-one errors in length checks.
Frequently Asked Questions
What is the difference between Base64 and Base64URL?
Base64URL is a variant of Base64 designed for use in URLs and file names. It replaces + with - and / with _, and omits the = padding characters. JWTs always use Base64URL for their header and payload sections.
Why does my JSON have a parse error even though it looks correct?
The most common causes are: trailing commas after the last element in an array or object (invalid in JSON but allowed in JavaScript), single-quoted strings (JSON requires double quotes), and unescaped special characters in string values. Paste the JSON into the JSON Validator to locate the exact problem.
What is percent encoding and when is it required?
Percent encoding (also called URL encoding) is required whenever a URL contains characters outside the safe ASCII set—specifically in query parameter names and values. Characters like spaces, ampersands, equals signs, and non-ASCII letters must all be encoded. The URL Encoder handles this automatically.
How do I convert a query string to a structured format for debugging?
Paste the raw query string (everything after the ? in a URL) into the Query String to JSON Converter. It parses each key-value pair and presents them as a formatted JSON object, making it much easier to see what parameters are being sent.