Encodingversion v1.0.0

Text Encoding Toolkit

Four schemes, both directions, over text that is always UTF-8: HTML character references, \uXXXX escapes, hex bytes and binary bytes. Decoding resolves all 2,231 HTML5 named references, not a convenient subset — a decoder that leaves — as literal text produces output that looks plausible and is wrong.

It is not an HTML parser and it does not sanitise anything. Escaping five characters is enough in element text and in a quoted attribute, and is not enough anywhere else — the panel beside the output says exactly where, and why.

Scheme

Direction

Escapes & < > " ' and nothing else. Non-ASCII passes through — <meta charset="utf-8"> is the fix for that, not é.

Input0 characters · 0 bytes UTF-8

Escaping five characters is not sanitisation. This output is safe in element text and in a quoted attribute, and nowhere else — see the table. A 200 from the endpoint is not approval either.

Output0 characters

Escaping is not sanitisation

& < > " ' become & < > " '. That is sufficient in three contexts and insufficient in six, and the difference is an XSS bug rather than a formatting one.

Safe to insert here
Safe	Element text `<p>HERE</p>`References are resolved here, so < and & cannot start a tag.
Safe	<textarea>, <title> `RCDATA`The parser resolves references, so </textarea> cannot close the element.
Safe	Quoted attribute `title="HERE"`Both quote characters are escaped, so neither can terminate the value.

NOT safe here — and why
Not safe	Unquoted attribute `title=HERE`A space, tab, newline, form feed, backtick, = or / starts the next attribute — x onmouseover=alert(1) needs none of our five characters. Quote your attributes.
Not safe	Inside <script> `raw text`Worse than insufficient: references are not resolved there, so < arrives in your JavaScript as six literal characters, while </script inside a string still ends the element. Use JSON.stringify and a <script type="application/json"> block.
Not safe	Inside <style> `raw text`Same raw-text rule, plus CSS has its own escape syntax and its own url() injection surface.
Not safe	Inside a comment `<!-- HERE -->`References are not resolved in comments, and --> or --!> closes one. The hyphen is not in our five.
Not safe	Event handler `onclick="HERE"`The parser resolves references first, then hands the result to JavaScript: ' becomes ' before JS ever sees it, so the escape is undone by design.
Not safe	URL attribute `href="HERE"`javascript:alert(1) contains none of our five characters. That is URL validation, not HTML escaping — /url?mode=parse&out=scheme is the tool for it.

Privacy

Everything on this page is transformed in your browser. Nothing is uploaded.

The page imports the same module the API uses and runs it here, so your input never reaches the server, a query string, a log or local storage. Refreshing discards everything. The honest asymmetry: the browser is local, the curl path is a network request — it transforms in memory and logs no body, but it is still a request.

Boundaries

Decode is not the inverse of encode: &, &AMP; and &amp all decode to & and all re-encode to &. Encode → decode is exact.
&#xD800; and  are refused. A browser answers U+FFFD there, which is a different character that no longer round-trips.
Base64 belongs to /base64, percent-encoding to /url, JSON string escapes to /json, and base conversion of a number to /number. We own byte views of text.

From the command line

The same URL answers a POST with the value and exactly one newline. Use --data-binary @-, never -d @-: -d strips newlines, and a newline is data here.

$printf '%s' '<a title='"'"'hi'"'"'>Ω 😀</a>' | curl -fsS --data-binary @- 'https://tools.primeforge.app/encode?mode=html&direction=encode'

$printf 'a&b' | curl -fsS --data-binary @- https://tools.primeforge.app/encode

$printf 'héllo' | curl -fsS --data-binary @- 'https://tools.primeforge.app/encode?mode=hex'

A non-2xx always means the request was wrong, never that the data was bad news: curl -fsS …/encode && publish is not a safety check, and there is no output value spelled safe.