EXIF Data Hider

An image file is its pixels plus metadata: camera details, dates, a location, free-text fields and an embedded thumbnail. Metadata steganography writes your payload into one of those fields instead of into the pixels. The pixels are left exactly as they were: in our tests the image data was byte-identical before and after hiding for every method in JPEG, PNG, TIFF and (for the methods tested) WebP. We did not run that test for HEIC.

The cost is visibility. Any EXIF viewer can show the field, and this tool's own data is base64 text behind a short header, so it is easy to spot by anyone who looks. Nothing here makes a file undetectable. And many social and messenger apps re-encode photos and rewrite their metadata, so the data may not survive being posted; we have not tested individual services.

Use UserComment for most messages: it is a standard field, holds the most data of the EXIF text fields, and every supported format has it. Use ImageDescription for short text when you want it to appear in viewers that show a caption. Use XMP for payloads above about 48 KB, but only in PNG, WebP or TIFF: a JPEG stores EXIF and XMP in segments of at most 64 KB, so XMP in a JPEG holds about the same as UserComment.

IPTC Caption, MakerNote and Thumbnail are JPEG-friendly extras (IPTC and Thumbnail are JPEG-only). GPS Coordinates holds 8 bytes at most, is never encrypted and has no length field, so a shorter message always comes back padded with zero bytes. The Extractor's Auto-Detect does not report a GPS result unless those 8 bytes read as printable text, because every geotagged photo would otherwise look like it holds a secret.

A JPEG keeps its EXIF in one segment whose length field is 16 bits, so it can never exceed 65,535 bytes, and the payload is base64-encoded inside it (4 bytes of text for every 3 of data). Measured on a plain JPEG, the real limits are about 49 KB for UserComment, 48.8 KB for XMP and 47.5 KB for the thumbnail, and the tool enforces figures just under those. A larger payload cannot be stored in a JPEG at all, so it is refused. Every encode also reads its own output back, and a file is offered for download only if it returns your data byte for byte.

A password adds 48 bytes to the payload (a 4-byte length, a 16-byte salt, a 12-byte IV and a 16-byte authentication tag). A carrier that already holds a lot of EXIF has less room than the table shows, and that is what the read-back check catches. PNG, WebP and TIFF carry XMP in chunks without the 64 KB limit: we tested 4 MB, including with a password, and did not look for the upper limit.

The Scrub tab reads the image, shows the privacy-relevant fields it finds, strips them in your browser and then re-reads the cleaned file so you can see what a scan still finds. The Orientation tag (when it is not the default) and the colour profile are kept so the picture still displays correctly. In the table below, "removed" means removed in our tests: we planted a unique marker in every location, scrubbed, and searched the output bytes for the markers.

A full scrub keeps only what the pixels need. It removes, among other things, the lens model, the unique image ID, JPEG comments, IPTC captions, the embedded thumbnail (a second, smaller copy of the picture), every PNG text chunk and timestamp, and a TIFF's description, XMP and whole Exif block. "Scrub before encode" on the Hide tab uses the same code; a GPS-only scrub is available for JPEG and TIFF, and every other format is scrubbed completely.

Two honest limits. Scrubbing removes metadata, not identifying content: a face, a street sign or a camera's sensor noise stays in the pixels. And the re-check after scrubbing uses this tool's own reader, so it is a sanity check rather than an independent forensic audit. Showing the GPS location on a map downloads map tiles from OpenStreetMap, which tells them the area (and your IP address); the map loads only after you click a button that says so.

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.

Reed-Solomon (XMP method only, Forensic mode) is a real Reed-Solomon code: 10, 20 or 30 parity bytes per 223-byte block repair up to 5, 10 or 15 changed bytes in that block. It repairs a few scattered edits. It does not help if an app rewrites the whole metadata block, which removes the payload entirely.

The "Plausible deniability" switch (Forensic mode) writes the payload without the EXIFsteg:v1 header, so Auto-Detect cannot find it; you must then choose the exact method and tick the same switch in the Extractor. The separate "Decoy + Real Payload" section (JPEG only) puts a plain decoy text in UserComment and your encrypted payload in MakerNote. Neither option makes the data invisible: the fields still exist and still hold unexplained text. Timestamp spoofing and the MakerNote camera profile change what the metadata claims about the photo; the MakerNote profile is a vendor signature prefix, not a faithful copy of a real camera's internal layout.

JPEG, PNG, WebP, TIFF and HEIC files up to 50 MB are accepted (15 MB or less is recommended on phones, because TIFF and HEIC need byte-level rewriting that can be slow on small devices; we did not time it). IPTC Caption and Thumbnail work in JPEG only; XMP does not work in HEIC. The tool's own XMP, MakerNote and UserComment output is read by the Extractor; it does not read hidden data written by other tools' layouts.