RAW EXIF Viewer: CR2, CR3, NEF, ARW, DNG

RAW files carry a rich EXIF block, and you can read it — a RAW EXIF viewer does not need to decode the image to do that. Canon CR2 and CR3, Nikon NEF, Sony ARW, Adobe DNG, Fujifilm RAF and Panasonic RW2 all store their metadata as a standard TIFF/IFD tree, the same structure used by JPEG, often alongside a full-size embedded preview. A RAW file is not a finished picture: it holds the sensor’s raw signal data (often 12–14 bits per channel, mosaiced on a Bayer grid), the metadata describing how to interpret it, and often a rendered JPEG preview so the file can be displayed by software that cannot process RAW. The complication is that the most interesting fields live in a vendor-specific binary MakerNote blob, and no browser can decode RAW pixels at all, so a “RAW viewer” is really two tools: a metadata reader and an image decoder.

The formats you will meet

Extension	Vendor	Container	Structural notes
CR2	Canon	TIFF-based	Since 2004; IFD0 holds camera info, IFD1 a full-size JPEG preview
CR3	Canon	ISOBMFF (box) structure	Since 2018 bodies; metadata in CMT boxes, preview in PRVW/thmb; 10-bit
NEF	Nikon	TIFF-based	“Small” and “large” variants; large NEF can contain two TIFF headers
ARW	Sony	TIFF-based	JPEG preview in IFD1; Sony MakerNote with SR2/SR3 private blocks
DNG	Adobe	TIFF-based, open spec	SubIFDs for the raw data, an optional lossy preview; written natively by some cameras
RAF	Fujifilm	Proprietary header	“FUJIFILMCCD-RAW” signature, a JPEG preview near the head of the file
RW2	Panasonic	TIFF-based	Panasonic-specific tags, some in private/reserved tag ranges
ORF, PEF, RWL, 3FR	Olympus, Pentax, Leica, Hasselblad	Vendor-specific	Each has its own container and MakerNote layout

CR3 is the outlier worth internalising: it is not TIFF at all. It is an ISOBMFF box file, structurally much closer to HEIF and MP4 than to CR2, so a parser written for TIFF needs a separate code path to find the Exif payload inside the CMT boxes.

How RAW stores its metadata

For the TIFF-based formats (CR2, NEF, ARW, DNG, RW2), the file starts with a TIFF header — byte-order mark (II or MM), a magic number, and an offset to the first image file directory. From there you get a tree of IFDs:

• IFD0 — Make, Model, ImageWidth, ImageHeight, Software, DateTime, Orientation, and often the pointer to the preview.
• Exif SubIFD — DateTimeOriginal, ExposureTime, FNumber, ISOSpeedRatings, FocalLength, LensModel, BodySerialNumber, and the MakerNote.
• GPS IFD — coordinates, altitude, timestamps, and heading.
• IFD1 — a thumbnail, which in CR2, NEF and ARW is typically a large JPEG preview of the frame.

In a JPEG the whole EXIF block lives in a few kilobytes of APP1 segment at the head of the file. In a RAW file the same IFD structure is embedded inside a much larger payload, scattered across several boxes or headers depending on the format. Reading it is straightforward byte work; the hard part is what the bytes mean.

MakerNote: where the interesting data hides

MakerNote (tag 0x927C in the Exif IFD) is a proprietary binary blob with no published specification. Each vendor invented its own layout, and each generation of a camera body may differ again.

• Canon — body serial number, shutter count, internal serial number, focus-point records, Picture Style.
• Nikon — lens data, shutter counter, VR mode, firmware, internal serial number.
• Sony — image ID, focus mode, white-balance bracket, SR2Private/SR3Private blocks on newer bodies.
• Fujifilm — film simulation, dynamic range setting, focus point, lens identification.
• DNG — the “unique camera identifier” (0xA435), a 32-byte hash tying every file from the same body to the same camera.

That last one matters for privacy: in a DNG the unique camera identifier is deliberately designed to be a durable link between files and a device.

Because MakerNote has no common format, general-purpose parsers surface the standard EXIF subset and either skip MakerNote or decode only what they have reverse-engineered for that vendor and model. Tools like ExifTool maintain per-vendor MakerNote decoders and are the reference implementation; a browser library that only walks IFDs will not give you the full picture. Read the EXIF tag reference to see what a field means, particularly the serial number, camera model, and lens model entries.

Why some tools only read the embedded preview

A common shortcut: find the JPEG preview inside the RAW file, decode that, and read the EXIF from the preview. It is fast, and the preview usually carries a copy of the interesting tags — but it is a lossy, downsampled render, and some vendors strip or reduce the metadata attached to the preview, so GPS or serial numbers can be present in the main structure and missing from the preview. If a tool shows GPS for one RAW and not another, that is often preview-parsing behaviour rather than a difference in the originals.

Why a browser cannot display a RAW file

There is no browser API for RAW, and the reason is fundamental rather than an oversight. To show a RAW you must demosaic the Bayer mosaic, apply the camera’s white balance, run the tone curve, and apply a colour profile — and each vendor does this differently, which is why RAW files are not interchangeable. Browser-based solutions therefore compile a decoder to WebAssembly: a LibRaw or dcraw-derived build is several megabytes and takes seconds on a phone. The alternative, and far more common, is to extract the embedded JPEG preview.

This split determines what a “RAW EXIF viewer” can promise: metadata inspection is cheap — byte-level parsing of the IFD tree, no decoder needed — while pixel rendering is expensive, requiring a WASM decoder or the embedded preview as a stand-in.

Inspecting RAW metadata safely

The safe routine is read-only, local, and needs no codec:

1. Open the freexifdata EXIF viewer.
2. Drop the .cr2, .cr3, .nef, .arw, .dng or .raf file onto the upload area.
3. The container is parsed in memory — no upload, no server-side processing, and your original file is never modified. EXIF, GPS, camera, lens, exposure and timestamp fields are grouped into the usual sections; use the GPS photo checker if coordinates are the concern.
4. If the file needs to be shared, sanitise it with remove EXIF data rather than handing over the original.

For a complete field-by-field dump including decoded MakerNote blocks, a desktop tool is better. ExifTool can rewrite a RAW’s metadata in place, which is the correct operation for a RAW file:

exiftool -all= IMG_1234.CR3

That edits the metadata structures and leaves the sensor data untouched — no re-encode, no quality loss. ExifTool keeps a _original backup by default.

What a sanitised export from a RAW can and cannot be

• If the browser can decode the file, you get a clean re-encoded image. For RAW that usually means the embedded preview, so the result is a JPEG-sized render, not a full development of the sensor data.
• If the browser cannot decode it, you get a complete metadata audit with the original file untouched — no pixel export. In that case, sanitise after converting to a standard format.
• A sanitised export is not a substitute for a proper RAW development. For colour-accurate output, use Lightroom, Capture One, or a DNG-aware converter and remove the metadata during conversion.
• For archival workflows, DNG is the most flexible target: open, widely supported, and writable with metadata removed while keeping the sensor data.

Cautions

• Metadata support differs per format and per camera generation. Treat any field you have not verified personally as “possibly absent” rather than “absent”.
• MakerNote contents are undocumented and change with firmware. A field that reads as empty in one tool may be present and unparsed in another.
• A preview-based read can be misleading. When a result matters — a forensic check, a privacy claim, a legal disclosure — read the IFD tree and confirm with a second tool, and keep the original card copy until the sanitised output is verified.