Text Obfuscator (Anti-Scraper)

Encode an email or text into a reversible obfuscated format so scrapers see garbage while humans and browsers can still read it.

Plain Text / Email

Obfuscated Output

Input Length: 0Output Length: 0

How the Text Obfuscator works

This tool converts plain text — most commonly an email address — into a reversible obfuscated encoding so it is unreadable to naive scrapers and regex-based harvesters, while remaining perfectly recoverable by a human or a browser. It supports three encodings:

HTML entity decimal codes — every character becomes a numeric character reference like @. Browsers render these back to normal text automatically when placed in HTML, so you can drop the output straight into a page's source and visitors see a normal, clickable address.
JS Unicode escapes — every character becomes a \uXXXX escape sequence, the same format JavaScript string literals use. Useful when you need to reconstruct the text at runtime with a small script (e.g. JSON.parse("\"" + escaped + "\"")) instead of relying on HTML rendering.
ROT13— rotates each Latin letter 13 places through the alphabet. It is not designed to defeat scrapers on its own (it's trivially reversible and well-known), but it is handy for lightly obscuring text in forum posts, spoilers, or puzzles. Applying ROT13 twice returns the original text.

This is different from the site's String Obfuscator tool, which performs irreversible homoglyph substitution (swapping letters for visually identical characters from other Unicode scripts) purely to defeat copy-paste text matching. The Text Obfuscator here is designed to be decoded again — either by a browser rendering HTML entities, by a small script reversing the escapes, or by running the same ROT13 operation a second time.

Note that none of these techniques stop a determined or JavaScript-capable scraper — they only raise the bar against the simplest regex-based email harvesters. For stronger protection, combine obfuscation with a contact form or a CAPTCHA-gated reveal.

Built and maintained by Meet Shah · Last updated 28 July 2026

What this tool is used for

Encoding an email address on a page so a naive scraper does not read it.
Producing HTML entity codes for a contact detail while keeping it readable in a browser.
Comparing the entity, escape and rotation approaches for one string.
Obscuring a short string in markup that humans still see normally.
Producing an encoded form for a template that renders it back.

Frequently Asked Questions

What encodings does it offer?: HTML decimal entities, JavaScript Unicode escapes, and ROT13. The first two render normally in a browser while showing nothing readable in the raw source; ROT13 is a plain letter rotation.
Does this actually stop email harvesting?: Only the simplest kind. A regex-based scraper reading raw HTML sees nothing, but any harvester that renders the page — which is cheap now — reads the decoded text exactly as a visitor does.
Is ROT13 encryption?: No, and it never claimed to be. It is a fixed letter rotation with no key, reversible by anyone who recognises it. Its real use is hiding spoilers from casual reading, not protecting anything.
Is HTML entity encoding safe for XSS protection?: Not as used here — this encodes text for obscurity, not for context-correct output escaping. Preventing injection requires escaping at the point of output, in the right way for HTML, attribute, URL or script context.
Does obfuscated text stay accessible?: Entity-encoded and Unicode-escaped text decodes to the identical string before assistive technology sees it, so screen readers are unaffected. ROT13 does not decode, so it is unreadable to everyone until reversed.
What protects an address better?: A contact form, or an address served only after an interaction. Both avoid publishing the string at all, which is the only approach that does not depend on the harvester being unsophisticated.

Common errors and gotchas

Believing it stops scrapers, since any scraper that renders the page reads the decoded text.
Breaking a mailto link's behaviour by encoding the parts a browser needs unencoded.
Harming accessibility, where a screen reader may announce the encoded form.
Assuming entity encoding is security rather than mild friction.
Encoding text that a search engine then cannot read either, which was not the intention.