HTML Steganography Hider

The carrier is a text file of HTML source: .html, .htm, .svg or .xml, up to 50 MB (10 MB on a phone). The hidden payload is typed text or one or more files, which are bundled into a ZIP first when you attach several. Nothing is converted: the output is the same markup with small edits, saved with the same extension.

The six methods write in different places in HTML source. Zero-Width Characters go after visible characters in text. HTML Comments are added after closing tags. Whitespace adds one space or tab at the end of a line. Attribute Order sorts the attributes of a tag in one of two orders. Case Variation writes a tag name in lower or upper case. Entity Substitution spells &, <, >, " and   in the named or the numeric form. The first reference table below lists what each method touches and what it skips. For XML, SVG and XHTML files some methods have extra restrictions: Case Variation is not available, Entity Substitution skips  , and Zero-Width and Whitespace follow XML-specific rules (see HTML, SVG and XML Files below).

Every method stores the same structure: a 4-byte length field followed by the stored data, written as a string of bits, one bit per slot. The stored data begins with a one-byte flag that says whether a file name follows (for a file, the name comes next, so a hidden file keeps its name), then your message or file. The length counts all of it: the flag, any file name, the 48 bytes added by a password and the Reed-Solomon parity, if you use them. For "Hi" with no password the length is 3 (00 00 00 03): one flag byte plus two message bytes. A slot is a place where the method can write one bit. The number of slots decides the capacity, so it depends on your file, not only on its size: two HTML files of the same size can have very different capacities because each method depends on different eligible places in the source. The tool counts the slots exactly before you encode.

On the figures page, Zero-Width Characters had the largest capacity by far, and it was the only method still readable after both tested transformations (an aggressive html-minifier-terser 7.2.0 run and a parse5 7.1.2 parse and re-serialise). It usually has the most room on pages with running text, while a page with no text, such as a tag-only template, has none. Results may differ with other files and other processing pipelines. Use it unless you need the file to look unchanged in a text diff, in which case nothing here is subtle: every method is visible to a tool that compares the file with the original.

Attribute Order, Case Variation and Entity Substitution change no visible character and add nothing, but they carry very little and are lost when the HTML is parsed and written out again. They suit small messages in files you control. Comments and Whitespace add visible text to the source.

To hide a message in plain text instead of an HTML file, use the Invisible Text Hider or the Unicode Steganography Hider. To hide data in a DOCX, XLSX or PPTX file, see Document Steganography.

A password encrypts the data with AES-256-GCM before it is written, with a key derived by PBKDF2 (100,000 iterations). Encryption adds 48 bytes. It hides the content, not the fact that something is hidden: the characters, comments or tag changes that carry the bits are still there.

Reed-Solomon is in Forensic mode (the third option of the Quick / Standard / Forensic switch at the top of the Configure step): the section is titled Error Correction (Reed-Solomon) and offers None, rs-10, rs-20 and rs-30. It adds a 16-byte header plus 10, 20 or 30 parity bytes for every 223 data bytes (levels rs-10, rs-20, rs-30) and can repair up to 5, 10 or 15 changed bytes per block. It repairs scattered changes inside the stored data. It cannot repair a method that was erased, for example comments removed by a minifier, and the 4-byte length at the start is not protected by it.

There is no compression step in this tool. The second reference table shows the stored size of a 100-byte message with and without a password and Reed-Solomon.

The tool opens .html, .htm, .svg, .xml and .xhtml. A file is treated as XML when its name ends in .svg, .xml or .xhtml, or when it starts with an XML declaration or an <svg> root element; everything else is treated as HTML. XML is stricter than HTML: tag names are case-sensitive, only five entities are defined (&amp; &lt; &gt; &quot; &apos;), and nothing except whitespace and comments may stand outside the root element. Three methods therefore behave differently on XML. Case Variation is not available (it refuses with a message). Entity Substitution leaves &nbsp; alone. Zero-Width never writes outside the root element. Whitespace only marks lines that end in a tag and is not used when the file contains xml:space="preserve".

These rules were checked on 20 real SVG and XML files (icons, a Maven POM, an RSS feed, Apple property lists) with the xmllint program: every output was still well-formed XML and had the same canonical XML as the cover once the embedded bits were ignored. Without them, Case Variation, Zero-Width and Entity Substitution each produced files that xmllint rejected. Other XML parsers, schema validators and editors were not tested.

Watermark Batch Export is on the result page. It makes one copy of your ORIGINAL file per recipient (the message you just hid is not in these copies), using the method you chose. Each copy hides a small JSON note: a watermark ID, the recipient's ID and a time stamp. It has no password and uses Reed-Solomon rs-10. The watermark ID is 128 bits derived with HKDF-SHA-256 from a random secret created for that run, the SHA-256 hash of the cover file and the recipient's ID, so every recipient gets a different ID. The secret is not saved anywhere and is not needed afterwards.

You get two downloads: a ZIP with one file per recipient, and watermark_keys.json, which lists every ID with the recipient's name, e-mail, the method and the time. Keep that key file to yourself and do not put it in the ZIP. To find out which copy leaked, open the leaked file in the HTML Extractor, then open Watermark Attribution and load watermark_keys.json: it compares the ID read from the file with the key file and allows a few wrong bits.

Up to 200 recipients are accepted per run; blank and repeated lines are ignored, and two recipients whose names would give the same file name get different file names. If a copy cannot be made (for example the cover has too few places for the method) it is left out of the ZIP, shown on screen and listed under "failed" in the key file. If no copy can be made, nothing is downloaded and the reason is shown. The IDs identify a copy only while the hidden note survives: a method that is removed by a minifier or an editor takes the ID with it.

If the cover already contains the characters or comments a method uses to carry bits, the tool removes them first and tells you how many it removed: U+200B and U+200C in text, comments or CDATA (Zero-Width; the Hider writes only into text, but the Extractor reads all three places, so none may be left), or comments made only of one or two spaces (Comments). Without that, the Extractor would read them as part of your message.

Nothing is ever written inside <script> or <style>, and attribute values are changed only by Entity Substitution, which respells entities there (both spellings mean the same thing to a browser). Whitespace is the exception that can change a page: a space or tab at the end of a line inside <pre> or <textarea> is part of that content. Compare the previews on the result page; the tool does not compare rendering for you.