Image Metadata Viewer and Remover

Two jobs: read the hidden blocks, then strip them

This tool runs 2 jobs, and the split explains what it can and cannot promise. Job 1 is reading metadata: parsing the bytes that sit beside the pixels and describe them. Job 2 is removing that metadata: producing a copy that carries 0 of it forward. Both run inside your browser on the local file you pick, so the picture is never uploaded. Reading is format-specific because each format hides data differently. A Joint Photographic Experts Group file, JPEG for short and standardised in 1992 and still behind over 70 percent of web photos, stores metadata in application segments flagged by 2-byte markers: an APP1 segment at 0xFFE1 beginning with the 6-byte string Exif (0x45 0x78 0x69 0x66 0x00 0x00) holds camera data across up to 65533 bytes, since a 2-byte length caps at 65535, a second APP1 beginning with a 29-byte Adobe namespace holds editing history, APP2 at 0xFFE2 holds the International Color Consortium profile, and APP13 at 0xFFED holds Photoshop and Information Interchange Model records.

Inside the Exif container

The Exif standard, first published in 1998, packs its payload as a miniature Tagged Image File Format structure. It opens with 2-byte order field, either 0x4949 for little-endian or 0x4D4D for big-endian, then the constant 42, a nod to a famous 42, as a sanity check, then a chain of Image File Directories, each of which this tool follows across up to 3 levels and 512 entries per level. Every entry is exactly 12 bytes: 2 for the tag, 2 for the type, 4 for the count, and 4 for either an inline value or a pointer. Anything of 4 bytes or fewer sits inline; longer values are fetched from an offset. This tool walks that chain, caps each directory at 512 entries as a corruption guard, follows tag 0x8769 into the Exif sub-directory and 0x8825 into the Global Positioning System block, and decodes 40-odd descriptors: make at 0x010F, model at 0x0110, software at 0x0131, orientation at 0x0112 with its 8 states, X resolution at 0x011A, Y resolution at 0x011B, resolution unit at 0x0128, exposure program at 0x8822, maker note at 0x927C, user comment at 0x9286, modified date at 0x0132, digitised date at 0x9004, exposure bias at 0x9204, aperture value at 0x9202, description at 0x010E, artist at 0x013B, copyright at 0x8298, exposure at 0x829A, aperture at 0x829D, sensitivity at 0x8827, shutter at 0x9201, metering at 0x9207, light source at 0x9208, flash at 0x9209, focal length at 0x920A, 35mm equivalent at 0xA405, colour space at 0xA001, pixel width at 0xA002, pixel height at 0xA003, and the capture stamp at 0x9003. Of the 12 TIFF type codes, this tool reads 8, spanning sizes 1 through 10, including the 1-byte byte, the 2-byte short, the 4-byte long, the 4-byte float, the 2-byte signed short, and the 8-byte rational built from 2 four-byte integers.

Portable Network Graphics, or PNG, released in 1996 and carrying up to 18 chunk types, works differently: its metadata lives in named chunks such as tEXt, zTXt, and iTXt for text, eXIf for an embedded block, tIME for a 7-byte timestamp, and pHYs for a 9-byte density record. WebP, released by Google in 2010 and now read by all 4 major browsers, wraps everything in a Resource Interchange File Format container whose 10-byte VP8X header carries 5 flag bits announcing which of Animation, Alpha, Exif, XMP, and profile follow.

Why location is the field that matters most

Of everything a camera writes, position is the 1 descriptor that turns a picture into a disclosure. A phone records latitude and longitude as 3 rationals each, so 6 numbers total, degrees then minutes then seconds, plus a 1-letter reference of N or S and E or W at 0x0001 and 0x0003, with altitude at 0x0006, a timestamp at 0x0007, the map datum at 0x0012, a date stamp at 0x001D, and a version at 0x0000. Decoded, that pins a capture to within 3 to 5 metres, roughly the width of 1 room, from just 6 stored numbers and 2 reference letters. A single holiday photo is harmless; a shot of your front door, your desk, or a child at a named school quietly ships your home address to anyone who opens the file. The stamps compound the leak: an original date at 0x9003 plus a digitised date at 0x9004 sketch a daily timeline down to 1 second across 2 separate tags, and a serial number, when present, links all of your last 100 or 1000 photos to 1 device. This tool counts the privacy-sensitive descriptors separately, so a single glance across the 3 summary tiles, showing total fields, privacy signals, and file chunks, tells you within 2 seconds whether an image, whether 1 kilobyte or 40 megabytes, is safe to share or needs cleaning first.

How the clean copy works, and its 1 honest cost

Removal here is re-encoding, not editing. The browser decodes your picture to a grid of pixels, paints that grid onto an offscreen HyperText Markup Language canvas, and asks the canvas to encode a brand-new file. A canvas holds only colours, 4 channels of 8 bits each for 32 bits per pixel, or 16777216 colours: it has no slot for an Exif block, a position directory, an Extensible Metadata Platform packet, or a text chunk, so all 4 kinds are simply absent from the result. That is why the method is thorough rather than selective. It does not hunt for the 10-odd position descriptors and delete them 1 by 1; it rebuilds the output from the only thing that survives the canvas, the visible image. For a JPEG the tool first fills the canvas white, because that format lacks an alpha channel and a transparent source would otherwise render as pure black at 0, 0, 0.

The honest cost is that re-encoding a JPEG or WebP file is lossy. The canvas re-compresses at the quality you choose between 50 and 100 percent, so the copy is not byte-identical and, at the lowest 3 or 4 steps below 60 percent, say 55, 50, or lower, can look softer. Choosing PNG output avoids that, because its compression is lossless, at the price of a file often 2 to 5 times larger, sometimes 10 times on a flat graphic. Either way the byte count shifts, because a different encoder built it. The pixels are preserved; the exact bytes are not. For stripping a location before posting, that 1 trade is almost always worth taking.

Where this fits a real workflow

The people who most need this are not photographers auditing 3 lenses; they are anyone publishing images at scale. A marketplace seller, a journalist shielding a source, an estate agent posting 20 or 30 listing photos across 5 properties, a parent sharing to a group chat: each gains from checking a file before it leaves the machine, because a server-side scrubber would demand uploading the very file whose location they want hidden. Reading first, then cleaning, in 1 local pass closes that gap. Inspect the descriptors, confirm the latitude and longitude are the 2 numbers you expected, create the clean copy, then re-upload it here and confirm it returns with 0 fields and 0 privacy signals. The verification loop is the whole point: you never trust a claim, because the tool reads its own output on any file up to 40 megabytes.

Quick reference

• Formats read: JPEG, PNG, and WebP, the 3 types the browser can also re-encode.
• JPEG blocks: Exif in APP1 at 0xFFE1, XMP in a second APP1, profile in APP2 at 0xFFE2, Information Interchange Model in APP13 at 0xFFED, plain text in the COM marker.
• PNG blocks: tEXt, zTXt, and iTXt text chunks, an eXIf chunk, plus a 7-byte tIME and a 9-byte pHYs chunk carrying 2 four-byte axes.
• WebP blocks: EXIF, XMP, and ICCP chunks in the RIFF container, with a 10-byte VP8X header whose 5 flags sit in 1 byte.
• Directory guard: each block is capped at 512 entries; a count above 100000 is rejected; offsets past the buffer end are skipped.
• Removal method: canvas re-encode at 32 bits per pixel, so 24 bits of colour plus 8 of alpha, dropping all 4 block kinds.
• Honest limit: JPEG and WebP output is lossy at 50 to 100 percent quality; PNG output is lossless but 2 to 5 times larger.
• Privacy: both jobs run locally; the image is never uploaded in either 1.
• Verify: re-open the cleaned file here and confirm 0 fields, 0 privacy signals, and 0 sensitive chunks.
• Type sizes: type 1 is 1 byte, type 2 is 1, type 3 is 2, type 4 is 4, type 5 is 8, type 7 is 1, type 9 is 4, type 10 is 8.