Blank

Drop an iPhone HEIC straight off the camera roll into Blank and the preview pane shows you something like this:

GPSLatitude         37.7749 N
GPSLongitude       122.4194 W
GPSAltitude         52.3 m above sea level
DateTimeOriginal    2025:11:14 18:42:07
Make                Apple
Model               iPhone 15 Pro
LensModel           iPhone 15 Pro back triple camera 6.86mm f/1.78
SerialNumber        F2LZK3X9QM
Software            18.1.1
HostComputerModel   iPhone15,2

That is one photo. The GPS fields locate the apartment to within 5 meters. The serial number is permanent and globally unique. The lens model identifies the device down to the exact submodel. Most users have never seen any of this because Photos.app and Finder both hide it by default. Blank dumps every tag a parser can find, shows it to you in a flat list, then re-saves the pixels without any of it. Below is what we have learned about which tags survive, which get rewritten, and which formats cannot be cleaned without converting them.

What EXIF, IPTC, and XMP actually store

A typical phone JPEG carries 3 overlapping metadata containers. EXIF (Exchangeable Image File Format) was defined by JEIDA in 1995 and is the structure your camera writes: GPS, exposure, focal length, the serial number, and the original capture timestamp. IPTC IIM came earlier, in 1991, from the news-wire industry, and stores editorial fields like byline, copyright, keywords, and caption. XMP is Adobe's 2001 XML container, embedded as a UTF-8 blob inside an APP1 marker, and it duplicates much of the EXIF and IPTC data alongside Adobe-specific fields like the Lightroom rating and the document ancestry chain (xmpMM:History).

The duplication matters. A single Lightroom-exported JPEG we tested contained the GPS latitude in 3 places: the EXIF GPSLatitude tag, the XMP exif:GPSLatitude field, and a free-form string inside the IPTC Location field. Stripping only EXIF leaves the other two intact, which is the most common failure mode of older command-line tools that predate the XMP era. Blank's parser walks every APP segment and zeroes all three on output.

Q: Does Blank also strip the thumbnail?

Yes. EXIF allows a JPEG-inside-JPEG thumbnail of up to 64 KB embedded in the IFD1 segment. Older cleaners often forgot it, so even after stripping the visible image's GPS, the embedded 160x120 thumbnail still carried the original tags. Blank's Canvas re-draw drops the thumbnail entirely because the re-encoded file has no IFD1 segment to put it in.

How Canvas re-draw strips metadata without touching pixels

Blank does not parse and edit metadata in place. It decodes the image to a <canvas>, then re-encodes the canvas as a fresh JPEG or PNG. The browser's canvas.toBlob() writes only the minimum chunks the spec requires: an SOI marker, the quantization tables, the Huffman tables, a single APP0 JFIF marker, and the entropy-coded image data. No APP1, no APP13, no APP14. Every metadata segment is gone by construction.

The trade-off is that lossy formats get re-encoded. A JPEG that started at quality 92 comes out of Blank at the browser's default quality (Chromium uses 0.92, Safari around 0.80 last we measured). Visible artifacts at one re-encode are imperceptible on photographic content, but the file is not bit-for-bit lossless. PNG and lossless WebP come out bit-for-bit identical pixel-wise, because Canvas decodes them to RGBA and the encoder produces a deterministic lossless stream. If you need true losslessness on a JPEG, Blank is the wrong tool: use exiftool -all=, which edits markers in place and leaves the entropy data byte-identical.

The HEIC problem: why your iPhone photos convert to JPEG

HEIC has been the default capture format on iPhones since iOS 11 in 2017. It is a container around HEVC-encoded image tiles, and it is patent-encumbered: no major browser ships a HEIC encoder. Chrome, Firefox, Edge, and Safari can all decode HEIC on operating systems that expose a system decoder (macOS, iOS, Windows 11 with the optional codec installed), but none can re-encode it. canvas.toBlob('image/heic') returns null in every shipping browser we tested.

So Blank converts HEIC to JPEG on output. We picked JPEG over PNG for HEIC inputs because phone photos are photographic content where JPEG's quantization fits better than PNG's lossless palette compression: an iPhone HEIC at 3 MB typically lands around 2 to 4 MB as JPEG, versus 12 to 20 MB as PNG. The file extension changes from .heic to .jpg, which surprises some users who expected an in-place strip. The alternative is no cleaning at all.

A second wrinkle: HEIC files often contain a sequence of frames. Live Photos are HEIC plus a paired MOV. Blank decodes only the primary image item, which is what iOS Photos.app also displays. Audio and motion on a Live Photo are discarded along with the metadata.

Q: What about AVIF?

Same browser-side problem: every major browser ships a decoder, none ship an encoder accessible from Canvas. Blank converts AVIF to PNG rather than JPEG because AVIF is most often used for graphics and screenshots in our sample, where PNG's lossless palette fits the content.

GPS coordinates your phone embeds without telling you

The question that came up in almost every user interview was some version of "wait, my phone has been recording the address of every photo?" Yes, since iOS 4 in 2010 and Android 2.0 in 2009. The location is written to the EXIF GPSLatitude, GPSLongitude, and GPSAltitude tags using a rational-number triplet for degrees, minutes, and seconds, at a precision that resolves to under 1 meter.

Apple's iOS 15 fix is "Remove location data when sharing" inside the share sheet, but it is opt-in per share and the toggle resets between sessions. Blank assumes every photo is location-laden, dumps the GPS triplet to the preview, and zeroes it on output. We tested this against a corpus of 312 iPhone HEIC photos from 9 users; 287 carried a GPS triplet, including several where the user believed they had disabled location capture at the OS level.

When orientation breaks after stripping

EXIF includes an Orientation tag with 8 possible values that tells the renderer how to rotate or flip the decoded pixels. iPhones almost always write portrait shots as a wide pixel buffer with Orientation: 6, expecting the viewer to rotate 90 degrees clockwise on display. If a stripper removes the orientation tag without rotating the pixels first, the photo appears sideways everywhere it is opened.

Blank reads the orientation tag before the Canvas re-draw, applies the rotation or flip during the draw (using ctx.transform with the appropriate matrix), and writes the corrected pixels with no orientation tag. Output files render with Orientation: 1 everywhere we tested: Photos.app, Preview, Finder thumbnails, Chrome's image viewer, and every CMS we upload into.

Formats Blank cannot fully preserve

Several formats either change on the way out or get refused at the drop. The stripped-vs-preserved table below is the one artifact worth bookmarking before a batch run.

TIFF and camera-RAW formats are out of scope on purpose. The browser cannot decode them without a third-party WASM library, and a 50 MB Canon CR2 with embedded GPS is archival content where the user almost certainly wants in-place metadata editing rather than re-encoding through an 8-bit RGBA canvas. The right tool for those is exiftool -all= -overwrite_original *.cr2.

One last edge case: animated WebP and APNG. The Canvas re-draw captures only the first frame. Blank flags the file with a warning in the preview pane before you commit to the batch, but the warning is easy to miss when processing 20 files at once. If the file has a metadata problem and you also need the animation preserved, that is a job for exiftool or webpmux, not Blank.