PDF Steganography Hider

A PDF is a collection of numbered objects — a Catalog, page dictionaries, content streams, font dictionaries, metadata — tied together by references. Readers ignore dictionary entries they do not recognise, and that is the space this tool uses: it adds an entry with a custom name that holds your payload as Base64 text, then saves the file again. The page content is not redrawn, so the pages look the same.

That makes it a way to attach data to a PDF without changing how it looks, not a way to make the data hard to find. Anyone who dumps the file's objects with a PDF tool can see the custom entries and the Base64 text. In files this tool wrote, a plain strings pass finds the Base64 only for Object Stream, because pdf-lib writes the other four entries inside Flate-compressed object streams (measured, see the limitations); any tool that inflates streams finds all five. Encrypt the payload with a password if the content must stay private; encryption hides what the data says, not that it is there.

A PDF is a set of numbered objects: a Catalog (the root), a Pages tree, one dictionary per page, content streams that draw the text and images, font dictionaries, and an Info dictionary with the title, author, keywords and dates. A cross-reference table (or a cross-reference stream) lists where each object starts, and newer files pack many objects into compressed object streams. Viewers draw only what the pages reference, and ignore dictionary entries whose names they do not know. That tolerance is the space this tool uses.

Keep the original: the tool never changes the file you chose, it offers a new one. Run the Extractor on the downloaded copy before you send it. If the file is digitally signed, hide first and sign afterwards, because saving the PDF again changes the bytes the signature covered. A password-protected PDF is refused; remove its protection first. There is no way to recover a lost password.

The hidden data is plain Base64 unless you set a password, so do not rely on it for confidentiality without one. Whoever receives the file can also see the original document metadata (unless you chose Strip) and the new custom entries if they dump the objects.

Metadata Embedding writes the payload into the Info dictionary's Keywords field, as the text STEGO_META_V1: followed by Base64 cut into 500-character pieces joined with ||. It also sets the Subject field to STEGO_V1. It is the easiest to see: Acrobat's Document Properties or any metadata viewer shows it.

Invisible Text Layer stores the Base64 payload in a Catalog entry named StegoITData, which is what the extractor reads. It also draws the same data as white text, 0.001 points tall, at coordinates (−9999, −9999) on page 1, so the file contains genuine off-page text. Whitespace Manipulation stores the payload in a page Resources entry named StegoWSData and prepends a small content stream to page 1: a comment line and up to 256 Tw (word-spacing) lines of 0.0001 or 0 that spell out the first 32 bytes. Those lines are not attached to any words, so they do not change the layout; the Resources entry is the copy the extractor reads.

Object Stream adds a new uncompressed stream object containing STEGO_OBJ_V1: and the Base64 payload, and references it from the Catalog under StegoObjStream. Font Encoding adds a StegoFontData entry to the first font dictionary it finds on any page (or to page 1's Resources if the PDF has no fonts), holding STEGO_FONT_V1: and the Base64 payload.

All five methods store the same thing — Base64 text under a custom key — in different places, and none uses the visible content of the page. They are equally capable of carrying your data; they differ in where an inspector would look. Metadata is the most conspicuous, because every PDF viewer exposes it. The other four sit in structural dictionaries that viewers do not show but that any object dump lists, and that a tool which rebuilds the file from its rendered pages would not keep.

So choose by purpose. Use Metadata when you want the simplest, most inspectable result. Use Object Stream for larger or binary payloads. Use the others when you want the data kept out of the metadata fields. If the content is sensitive, set a password, whichever method you pick.

All five methods share one limit: 10,485,760 bytes (10 MiB). It is this tool's own enforced limit on the prepared payload, counted after the 1-byte filename frame (plus a length byte and the name for a file), the 48 bytes a password adds, and any Reed-Solomon parity. It is a memory and time policy, not a structural limit of PDF and not a promise that other software will open the result. The capacity bar shows it for every method; a payload at the displayed figure is accepted and one byte more is refused (tested at the boundary). A 10 MiB (10,485,760 bytes) payload takes about 0.2 s (Object Stream) to 7 s (Metadata) in Node on a laptop, including the read-back check, and the work runs in a Web Worker.

Four methods (Metadata, Invisible Text, Whitespace Manipulation, Font Encoding) store the payload in a PDF string; Object Stream stores it in a stream and is the better choice for large payloads. ISO 32000-1 Annex C lists 32,767 bytes as an implementation limit for a PDF string. As approximate compatibility guidance only: Base64 text of 32,767 characters holds about 24 KB of payload (about 12 KB for Metadata, whose Keywords field pdf-lib writes as UTF-16 with a 2-byte marker, two bytes per character: checked on real output), so a larger payload may open in this tool's Extractor but not in other software. Those figures are about the Base64-encoded size, not the original file size, and we did not test which readers enforce the limit.

The file grows by different amounts. Measured on incompressible data in a 3-page PDF, the output grew by about 1.0 times the payload size for Whitespace and Font Encoding, 1.3 times for Object Stream, 1.5 times for Metadata and 2.3 times for Invisible Text (which stores the payload twice, in the Catalog and as page text). Text payloads compress better, so those figures are an upper bound.

Without a password the payload is stored as plain Base64 and anyone who finds it can read it. With one, it is encrypted before it is embedded — see "How Strong Is the Encryption?" below for the exact scheme and its limits.

The RS-10, RS-20 and RS-30 options add Reed-Solomon parity: 10, 20 or 30 parity bytes per 223-byte block plus a 16-byte header, repairing up to 5, 10 or 15 changed bytes per block (the code's theoretical correction capacity, assuming the damaged block can be located; the 16-byte RS header is not covered by the parity). For a PDF it adds little, because the payload sits in the file as one intact string rather than being spread over pixels or samples that a re-encode might damage. We suggest leaving it off.

Anything that rewrites the PDF from its rendered pages — print to PDF, flattening, many optimisers, scanning — will not carry custom dictionary entries across. A re-save with the same library (pdf-lib load and save) kept all five methods in our tests; we have not tested Acrobat, Preview, Ghostscript, PDF/A converters, e-signature services or Google Drive, so treat them as untested rather than safe. Editing metadata can wipe the Keywords field.

Modifying a digitally signed PDF invalidates its signature, because this tool saves the whole file again. Embed before you sign. Password-protected (encrypted) PDFs are not supported: remove the protection first.

If you set a password, the payload is encrypted before it is hidden, in your browser, with the Web Crypto API. The cipher is AES-256 in GCM mode. The 256-bit key is derived from your password with PBKDF2 using HMAC-SHA-256 and 100,000 iterations. Every encryption generates a fresh random 16-byte salt and a fresh random 12-byte IV with the browser's cryptographically secure random generator (crypto.getRandomValues), so encrypting the same message twice gives different bytes. The stored layout is a 4-byte length, the salt, the IV, then the ciphertext followed by a 16-byte authentication tag — 48 bytes added in total. The tag means a wrong password, or any change to the ciphertext, makes decryption fail instead of returning garbage.

These are standard, widely used primitives, but this implementation has not had an independent audit, and using them does not make the system unbreakable. Their limits matter. Anyone who finds the hidden data can copy the ciphertext and try passwords against it offline, so your password is the real defence: use a long random passphrase, not a word or a date. The key derivation uses 100,000 PBKDF2-HMAC-SHA-256 iterations. This is below OWASP's commonly cited 600,000-iteration recommendation for password storage. That recommendation is not a direct requirement for this file-encryption format, but the lower count makes a strong, unique password especially important. The iteration count is fixed in the code and is not written into the file, so raising it requires a new, versioned format so that files already made can still be opened.

Encryption hides what the data says, not that it exists, and it does not hide the length: AES-GCM ciphertext is the same length as the plaintext, and the encrypted layout adds a fixed 48 bytes of overhead: its own 4-byte length field, the salt, the IV and the authentication tag, separate from any length or framing the tool puts around it. No padding is added. There is no key file and no way to recover a forgotten password. We have not measured key-derivation time on phones or older devices, so very large batches or slow devices may take noticeably longer per file. The tool is intended for educational and personal use; do not rely on it as the only protection for sensitive information, or against a well-resourced adversary.