Most guides to photo privacy give the same advice: strip the EXIF, remove the GPS, clear the metadata. If you’ve done that, the file is anonymous. The camera model is gone. The timestamp is gone. The coordinates are gone.
MakerNote is still there.
It’s a block of data that camera manufacturers write inside almost every photo you take — alongside standard EXIF but separate from it. Most EXIF stripping tools don’t touch it. Some don’t read it at all. Inside it, manufacturers have recorded things they chose not to standardise: lens serial numbers, shutter actuation counts, burst identifiers, scene recognition results, capture method, barometric pressure. The level of detail varies by brand. The pattern is consistent — manufacturers write more than the EXIF standard requires, in a binary format only they fully document.
What is MakerNote?
The EXIF specification (JEITA CP-3451C) reserves a single tag — 0x927C — for manufacturer use. The tag is called MakerNote. The EXIF standard says almost nothing about what goes inside it: structure, field names, and data types are all left to the manufacturer. There is no public specification for most brands. The content is proprietary binary data that varies by make, model, and firmware version.
This is not an oversight. Camera manufacturers have always recorded device-specific state beyond what the EXIF standard accommodates. The MakerNote block is where that data lives.
What each manufacturer records there differs considerably:
Canon stores shooting mode, AF point, lens type code, lens serial number, a firmware build identifier more specific than the standard EXIF firmware string, and an image type field that distinguishes originals from re-saves.
Nikon records scene recognition data, shutter actuation count — the total number of shots taken on that specific camera body — picture control settings, and lens and flash information beyond the standard EXIF fields.
Apple records barometric pressure, front/rear camera identifier, capture method (timer, lock screen shortcut, third-party API, burst), image stabilisation state, and a burst UUID — a shared identifier across every frame captured in a single burst sequence.
Samsung and other Android OEMs typically encode the device model string, software build fingerprint, and camera application version — often duplicating fields present in standard EXIF, but with greater specificity than the standard fields carry.
Sony, Olympus, Fujifilm, Panasonic, and DJI maintain their own MakerNote schemas. Field count and technical depth vary, but the pattern is the same: the manufacturer chose to record state that the standard EXIF IFD doesn’t accommodate.
Why EXIF stripping leaves MakerNote intact
EXIF is organised as a series of Image File Directories (IFDs). A standard EXIF strip removes the well-known IFDs — IFD0 for primary image data, ExifIFD for capture parameters, GPSInfo for location. Most EXIF tools were built to read and write these standard IFDs. MakerNote is a sub-IFD attached to the MakerNote tag inside ExifIFD, and its internal layout is opaque to tools that don’t have manufacturer-specific parsing logic.
The complication is that many manufacturers write MakerNote with self-referential byte offsets — the internal pointers are relative to the start of the MakerNote block, not to the file start. If a tool moves or rewrites the block without accounting for this, the internal offsets break and the data becomes unreadable. Some tools resolve this by not touching MakerNote at all rather than risk corrupting it. The result: a file with GPS coordinates removed, timestamps cleared, camera model stripped — and a complete MakerNote block intact, carrying lens serial, shutter count, or burst UUID.
Other tools zero out the tag pointer while leaving the binary data in place. The MakerNote tag points nowhere, but the bytes remain in the file and can be recovered from the raw binary.
There are two reliable approaches to actual removal. The first is overwriting the MakerNote bytes directly — tag removal alone is not sufficient, but zeroing the bytes is. The second is more thorough: strip the entire EXIF block and rewrite metadata from scratch. Because MakerNote lives inside ExifIFD, deleting the whole EXIF structure takes MakerNote with it. When you rewrite metadata from scratch you control exactly what goes back in — and MakerNote simply doesn’t, because no tool writes it on your behalf. The trade-off is worth understanding: a file with no camera-written EXIF, or with metadata that was clearly written by software rather than firmware, is itself a forensic signal. That absence is detectable — and is one of the things snapWONDERS flags.
This affects every popular format that embeds EXIF — JPEG, TIFF, PNG (via the eXIf chunk, standardised in PNG 1.6), and WebP (which stores EXIF in a dedicated chunk within its RIFF container). When a JPEG with MakerNote is converted to PNG and the conversion tool preserves EXIF, the MakerNote block travels with it intact. It affects files shared from phones, exported from cameras, and uploaded to services that strip EXIF server-side before distribution. Whether a particular tool removes MakerNote completely depends on whether its author specifically addressed it — and most tools don’t document either way.
What forensic analysis finds in MakerNote
The forensic value of MakerNote data falls into a few distinct categories.
Device identity beyond the model name. Standard EXIF records make and model as text strings. MakerNote records the internal identifier of the specific device. Nikon’s shutter actuation count is unique to a camera body — two photos from the same camera will have sequential counts, confirming shared device provenance even when all other metadata has been removed. Canon’s lens serial number ties an image to a specific piece of glass, not just a camera model. Apple’s front/rear camera flag identifies which physical sensor was used in cases where the standard EXIF model field is ambiguous.
Editing and re-save history. Canon’s MakerNote ImageType field distinguishes between a straight-from-camera JPEG, a RAW-developed JPEG, and a file that has been opened and re-saved in editing software. This distinction survives even when the standard EXIF Software tag has been removed or overwritten. The field reflects a file’s processing history at a level standard EXIF does not preserve.
Capture context and behaviour. Apple’s MakerNote records whether a photo was taken via a burst, a timer, the lock screen shortcut, or a third-party application. This capture context record does not exist in standard EXIF. Two photos with identical standard metadata may have completely different MakerNote capture contexts — meaningful in any situation where the circumstances of capture are at issue.
Secondary location data. The GPSInfo IFD — standard EXIF — is the primary location record and the one most stripping tools target. Some Android OEMs record approximate location data inside MakerNote as part of scene-recognition or horizon-levelling routines. This secondary location record survives EXIF strips that only target GPSInfo.
The absent MakerNote — when missing data is the finding
MakerNote presence is forensically significant. MakerNote absence can be equally so.
Writing a MakerNote block is not optional behaviour — it’s baked into camera and phone firmware and produced on every capture. There is no user-facing setting to disable it. If MakerNote is absent from a file that came from a device whose firmware always writes it, the block was removed by something after the original capture.
snapWONDERS records MakerNote presence as a signal against each device profile. Across a sufficient sample of images from a given camera model, consistent MakerNote presence becomes part of that device’s established fingerprint. When a submitted file claims to come from one of those devices and the MakerNote block is missing — while everything else in the file matches the claimed make and model — the absence is a finding. The file was processed by something that stripped the block. That processing step is itself a forensic fact, independent of whether anything in the image was changed.
You can’t turn MakerNote off in firmware. If it’s gone, something removed it.
The persistence problem
This builds directly on the camera fingerprint research covered in this series. Your camera’s fingerprint survives EXIF stripping — here’s how showed that the imaging pipeline leaves a statistical signature in the compression structure — one that persists through metadata removal and in many cases through reprocessing. MakerNote is the explicit, structured version of the same problem: not a side-effect of how images are encoded, but data the manufacturer chose to write, in a block most stripping tools chose not to remove.
The MakerNote blob also builds a profile in aggregate — including for fields that haven’t been decoded.
Every camera running identical firmware generates a MakerNote with the same internal structure: the same byte offsets, the same field layout, the same fixed values for internal versioning and device identifiers. Variable fields — shutter count, scene recognition data, exposure settings — shift from photo to photo, but they shift at consistent positions within the block. Fixed fields don’t shift at all. With enough samples from the same make, model, and firmware version, a statistical picture emerges: these bytes never change, those bytes vary within a known range, those bytes increment in a pattern. The structural fingerprint of the MakerNote for that firmware becomes known — not from the manufacturer’s specification, but empirically. The cameras themselves, at sufficient volume, provide the data.
The forensic implication is significant. Two photos from the same physical camera body will have matching fixed fields and predictably sequential variable fields. With a solid per-model baseline established, the question “did these two photos come from the same physical device?” becomes answerable at high confidence from the raw binary alone — not just from decoded, named fields like shutter count, but from the blob structure as a whole.
This is where AI-assisted analysis extends beyond what field-by-field decoding reaches. For manufacturers whose MakerNote schema is entirely undocumented, a model trained on sufficient samples can learn which byte ranges are structurally diagnostic for a given firmware, flag when a submitted file’s MakerNote doesn’t fit the expected structural profile for the claimed device, and cluster photos by camera body from the binary fingerprint rather than decoded field values. The manufacturer never needs to publish a specification for the analysis to become possible.
The confidence is probabilistic, not absolute. Fixed fields are near-certain. Statistical inference on unknown byte ranges carries error rates that depend on sample size and field entropy — findings from that layer are likelihood assessments, not determinations. For well-sampled devices on known firmware the confidence is very high; for less common devices or firmware variants it is lower. snapWONDERS is accumulating exactly the sample data this requires, building the per-model baseline that makes structural fingerprinting possible at scale.
The practical implications of both decoded and structural MakerNote analysis fall into several contexts.
Content authenticity. Journalists and fact-checkers use MakerNote fields to verify that a photo came from the device and software the submitter claims — or to surface inconsistencies that don’t hold up. A Canon MakerNote inside a file claimed to have come from a phone. An Apple burst UUID on a photo presented as a standalone capture. A shutter count that places the image earlier in the camera’s operational life than the claimed date. Each is a finding worth investigating.
Legal and investigative proceedings. Sequential shutter counts across images place them in chronological order even when timestamps have been altered. Lens serial numbers tie images to specific equipment. In proceedings where photo evidence is contested, MakerNote has been used to corroborate or contradict claimed metadata.
Privacy. Files that have been through a standard privacy scrub — EXIF stripped, GPS removed — may still carry a manufacturer-written block identifying the specific device, its firmware version, and in some cases the exact capture context. Whether that matters depends on the situation, but most users have no way of knowing whether their EXIF tool handled MakerNote at all.
Beyond MakerNote — what else manufacturers embed
MakerNote is the most studied part of the manufacturer data story. It isn’t the only part.
Some manufacturers implement cryptographic digital watermarking — a signature embedded in the pixel data itself, not the metadata, designed to verify that an image came from a specific authenticated device. Canon’s Original Data Security Kit and Nikon’s Image Authentication system both work this way. The watermark is invisible to visual inspection. If the image is modified after capture, the signature verification fails — it’s a tamper-evidence system. It operates at a different layer than MakerNote: the metadata can be stripped completely, and the pixel-level signature is still there.
Beyond that, manufacturers use proprietary XMP namespaces to record additional capture data outside the EXIF structure. Embedded ICC colour profiles can carry manufacturer-specific calibration data. Professional and broadcast camera manufacturers include data tracks specific to their own ecosystems. The C2PA (Coalition for Content Provenance and Authenticity) standard — now being implemented directly into camera firmware by Leica, Nikon, Sony, and others — cryptographically binds provenance metadata to the image at the moment of capture, creating a verifiable chain of custody that travels with the file.
And then there are the methods that aren’t publicly documented.
What manufacturers embed beyond what’s been reverse-engineered, what sits in pixel data versus metadata, and how forensic analysis handles these signals is worth a full article on its own. The short version: MakerNote is the part of the iceberg that has been mapped. The rest of it is there — and the industry is adding more, not less, as provenance and authenticity become central concerns in an era of generative AI.
How to check your photos
If you’ve read the earlier articles in this series — How I built a JPEG encoder fingerprint database from scratch and How to tell if a photo has been edited — you’ll know that the DQT fingerprint analysis looks at compression tables the JPEG encoder used: a signal independent of metadata. MakerNote is the metadata-layer parallel — specific, structured data that survives the strip most users believe completes the job.
snapWONDERS decodes MakerNote for all major manufacturers — Canon, Nikon, Apple, Sony, Samsung, Fujifilm, Olympus, Panasonic, and DJI — and surfaces the decoded fields alongside standard EXIF in the analysis output. Where the manufacturer schema is known, fields are decoded into labelled, human-readable values: lens serial, shutter count, capture method, and so on. Where the exact internal structure hasn’t been mapped, snapWONDERS renders the raw binary blob directly — the data is still surfaced, even when specific field names can’t be assigned to it. Either way, the block is never skipped.
The analysis also flags the specific combination of an unstripped MakerNote block alongside an otherwise cleared standard EXIF — the pattern indicating an incomplete privacy scrub — and, conversely, the absence of a MakerNote from a device profile where one is consistently expected.
Upload any photo and check what the manufacturer left behind.
→ Run any photo through snapWONDERS forensic analysis
Stripping EXIF removes what the standard defines. MakerNote is what the manufacturer decided to add. And its absence tells its own story.
Kenneth Springer is the founder of snapWONDERS and developer of Vaultify. The MakerNote decoding described in this article — Canon, Nikon, Apple, Sony, Samsung, Fujifilm, Olympus, Panasonic, DJI, and others — runs automatically as part of the metadata analysis on every uploaded file. snapWONDERS surfaces both decoded fields and the raw binary blob, and flags MakerNote absence from device profiles where presence is expected. snapWONDERS forensic analysis — no account required.