Web Encoding Decision Guide

Quick decision path

Encoding is not one interchangeable operation. Choose it from the boundary the data is crossing:

Putting a value inside a URL component? Use percent encoding for that component.
Carrying bytes through a text-only field? Use Base64 when the receiving format expects it.
Displaying reserved characters as text in HTML? Use HTML escaping in the correct HTML context.
Placing text inside a JSON string? Use JSON string escaping, normally by calling a JSON serializer.
Representing a Unicode code point with escape notation? Use a Unicode escape only when the target language or format supports that notation.

These operations solve different syntax problems. None of them encrypts data, proves safety, or grants permission to place untrusted input into every context. The safest default is to use the serializer or context-aware encoder supplied by the system producing the final document.

Start with three questions

Before opening an encoder, identify:

What is the input? Human-readable text, already-encoded text, or arbitrary bytes?
Where will it go? A URL path segment, query value, HTTP field, HTML text node, HTML attribute, JSON string, source-code literal, or database field?
What will decode it? A browser, URL parser, JSON parser, application framework, shell, or a protocol-specific consumer?

The destination defines the rules. The string A&B needs different treatment as an HTML text value, a query parameter, and JSON data. “Encode special characters” is therefore incomplete advice unless it names the destination context.

URL percent encoding

URLs use reserved characters as structure. In a query, & often separates parameters and = separates a name from a value. If the literal value is tea & toast, inserting it unchanged can change how a parser divides the query.

A component encoder represents characters with percent-prefixed byte values. For example, a space is commonly represented as %20, and an ampersand inside a component becomes %26. The conceptual result is:

Original value: tea & toast
Encoded value:  tea%20%26%20toast

Use the URL Encoder & Decoder to inspect a component transformation. In application code, prefer the URL-building API for your language. It can distinguish a path, query name, query value, and full URL.

Do not blindly encode an entire URL. Encoding : and / that are acting as URL structure can turn a valid address into a plain string. Likewise, decoding a complete URL before validation can reveal separators that change its meaning. Parse first, then operate on the intended component.

Form submissions introduce another detail: the application/x-www-form-urlencoded convention often uses + for a space, while a literal plus sign must be encoded. Do not assume every query parser and every percent-decoder applies the same plus-sign rule.

Base64

Base64 maps bytes to a restricted ASCII alphabet. It is useful when a text-only container must carry binary data or when a protocol explicitly requires Base64. Common examples include some email bodies, data URLs, and API fields that define their value as Base64.

Text interpreted as UTF-8: ToolSeta
Base64 text:             VG9vbFNldGE=

Use the Base64 Encoder & Decoder to explore text examples. Be precise about the byte encoding: Base64 encodes bytes, not abstract characters. Two systems must agree on how text became bytes—commonly UTF-8—before the decoded bytes become the same text again.

Base64 is not encryption. Anyone who recognizes it can decode it, and the output is usually larger than the original byte sequence. It does not make a secret safe in a URL, source file, log, or client-side token. It also does not validate whether decoded data is trustworthy.

Line breaks, URL-safe alphabets, and padding rules vary by protocol. Standard Base64 commonly uses +, /, and =; a URL-safe variant substitutes a different alphabet and may handle padding differently. Follow the receiving protocol rather than guessing from the visual shape of a string.

HTML entities and HTML escaping

HTML gives characters such as <, >, &, and quotes syntactic roles. When untrusted text is meant to appear as text, it must not be interpreted as markup. For an HTML text node, escaping can produce:

Text:    5 < 8 & 9 > 3
HTML:    5 &lt; 8 &amp; 9 &gt; 3
Visible: 5 < 8 & 9 > 3

The HTML Entity Encoder & Decoder is useful for learning and checking a small fragment. Production templates should use their framework’s automatic escaping instead of manually assembling HTML.

Context matters. Safe encoding for text between tags is not automatically safe for an attribute, inline script, inline style, URL-valued attribute, or event handler. Avoid placing untrusted data in dangerous contexts; when placement is necessary, use a library designed for that exact context.

Decoding entities before storing or validating input can also be risky if the decoded value is later inserted as markup. Track whether a value is raw, validated, encoded for a particular output, or already decoded. An encoded string is not globally “safe”; it is prepared for one boundary.

JSON string escaping

JSON strings use double quotes as delimiters and backslashes to introduce escapes. A literal quote, backslash, newline, carriage return, or control character inside the value must be represented according to JSON string rules.

Value with a line break: first line ↵ second line
JSON string content:     first line\nsecond line

Use the JSON String Escape & Unescape tool to examine a string. For complete objects or arrays, use a JSON serializer instead of concatenating fragments. A serializer knows where string boundaries belong and prevents a value from accidentally becoming object syntax.

Escaping a string does not create a complete JSON document by itself. If a tool returns escaped content without surrounding quotes, the caller still needs to place it in a valid JSON string. Conversely, running a serializer twice can turn intended escapes into literal backslashes. Inspect the data after each boundary rather than adding backslashes until an error disappears.

JSON escaping is also not the same as JavaScript-source escaping. JSON has a defined data grammar, while a JavaScript source file has additional syntax and execution concerns. Parse JSON as data; do not execute it as code.

Unicode escapes

Unicode assigns code points to characters. Some formats allow an escape such as \u0041 to represent A. Escapes are notation inside a particular grammar; they are not a replacement for a consistent character encoding such as UTF-8.

Use the Unicode Escape Converter when you need to inspect supported escape notation. Be careful with characters outside the Basic Multilingual Plane: some systems represent them as one code point escape form, while UTF-16-based grammars may use a surrogate pair. A visible character can also be composed from multiple code points.

Two visually identical strings may have different underlying code-point sequences. That matters for identifiers, comparison, searching, and security review. Unicode normalization is a separate operation from escaping. Do not promise that converting to escapes makes look-alike text unambiguous.

Comparison by job

Use this compact reference when the requirement is clear:

URL percent encoding: protects URL component structure while carrying text. Decoder: a URL or form parser.
Base64: carries bytes through a text-only channel. Decoder: a Base64 implementation using the expected alphabet and padding rules.
HTML escaping: keeps data from becoming HTML syntax in a named context. Decoder: an HTML parser.
JSON escaping: keeps string content inside JSON string syntax. Decoder: a JSON parser as part of a complete JSON value.
Unicode escaping: spells code points using notation supported by a target grammar. Decoder: that language or format parser.

If the receiving side cannot name the expected operation, stop and confirm the interface contract. Guessing between these formats produces data corruption at best and a security boundary error at worst.

Common failure patterns

Double encoding

An already percent-encoded value containing %20 may become %2520 when the percent sign is encoded again. An HTML entity can become visible text like &lt; after an extra escaping layer. Record which layer owns encoding and apply it once at the final output boundary.

Decoding too early

If data is decoded before parsing or authorization checks, newly revealed separators may be interpreted as structure. Validate using the form that the next parser will actually consume, and avoid chains of decode-and-reparse steps.

Treating encoded data as validated data

Encoding preserves syntax; validation enforces rules. A percent-encoded path can still name a forbidden location. Base64 can still contain an executable or oversized payload. A valid JSON string can still contain an unsafe command. Apply size, type, allow-list, authorization, and business-rule checks separately.

Mixing bytes and characters

If one side uses UTF-8 and another interprets bytes with a different character encoding, round trips can produce replacement characters or corrupted text. Name the character encoding at system boundaries and include non-ASCII test cases, not only English letters.

A repeatable boundary test

For any encoding workflow, test a small set containing a space, plus sign, ampersand, percent sign, quotes, backslash, angle brackets, a line break, an accented character, and an emoji. Then verify:

the producer emits the documented format;
the real consumer—not only the same tool—decodes it correctly;
one round trip restores the original intended value;
a second accidental encoding is detectable;
malformed input fails clearly rather than being silently changed;
size limits are enforced before expensive decoding or parsing;
logs do not expose secrets merely because the value looks encoded.

Keep the test beside the interface contract. A stable, reproducible example is more useful than a vague note saying “special characters are supported.”

Final rule

Encode for the destination context, as late as practical, with the destination’s own serializer or API. Decode only when the next operation requires the raw value. Keep validation, authorization, confidentiality, and integrity as separate controls. If you link to this guide in a code review or API document, name the exact section that defines your boundary.