An EXIF viewer is a tool that decodes the structured metadata embedded inside a JPEG file by the camera or phone that captured it, surfacing fields like the camera make and model, lens, exposure time, f-number, ISO, capture timestamp, image dimensions, and GPS coordinates. A browser-based viewer performs that decode locally in the current tab, reading the file's APP1 segment, validating the TIFF header, and walking bounded IFD0, Exif, and GPS directories without uploading a single byte. Because it uses a documented common-tag allowlist (orientation, exposure, ISO, focal length, lens model, latitude, longitude, and a small set of timestamps and identifiers), the tool stays predictable: it reports only what the JPEG actually carries and intentionally ignores proprietary maker notes rather than guessing at their meaning. Files up to 25 MiB are accepted; anything larger, or anything in a non-JPEG container, sits outside the supported scope and is handled by a different class of tool.
What EXIF Metadata Actually Lives Inside a JPEG
A JPEG is not just a stream of compressed pixels. Right after the standard SOI marker, most cameras embed one or more APP1 segments, and inside one of those segments lives a small TIFF-structured block. That block contains a header that declares the byte order (little-endian or big-endian), a magic number, and a chain of Image File Directories. The first directory (IFD0) carries general information such as the camera make and model, the software that wrote the file, the pixel dimensions, and an orientation tag that tells a viewer how to rotate the image. A pointer from IFD0 leads to an Exif subdirectory, which holds the capture-time fields: the original capture timestamp, the modified timestamp, exposure time, f-number, ISO speed rating, focal length, and the lens model. A second pointer leads to a GPS subdirectory, which carries latitude, longitude, altitude, and the hemisphere references needed to interpret them.
The TIFF container is compact, but it is also strict. Field counts, byte offsets, and tag identifiers all have to agree, otherwise a parser cannot tell where one field ends and the next begins. The EXIF Viewer walks that structure one bounded directory at a time and surfaces only the fields it can identify by their standardized tag numbers, which is why the output table is short and predictable rather than overflowing with hundreds of speculative entries.
Why a Local, Browser-Based Viewer Changes the Privacy Math
Uploading a photo to read its metadata is a strange workflow when you stop to think about it: the file leaves your machine, sits on a remote server long enough to be parsed, and may be cached or logged along the way. For casual browsing that is fine, but it is a poor fit for photos that may contain a home address in their GPS block, a workplace visible in the background, or simply a file you do not want to hand to a third party. A browser-based EXIF viewer sidesteps the issue by reading the bytes in the current tab. Nothing is transmitted; the parsed values live in the page until the tab is closed.
This local-only property is also what lets the viewer apply safety limits aggressively. Because the bytes are right there, the tool can reject malformed segment lengths, directories with excessive entries, offsets that point outside the selected file, and unsupported or oversized field counts before any value is rendered. Those checks are cheap when you control the whole read path, and they prevent the parser from being talked into reading past the end of the buffer or interpreting junk bytes as fields.
How to Inspect a JPEG's Metadata with EXIF Viewer
- Open EXIF Viewer in your browser. No install, sign-in, or extension is required.
- Choose a local JPG or JPEG file from your computer. The supported ceiling is 25 MiB; larger files, or files saved in a different container, are not accepted.
- Wait for the parser to locate the first valid APP1 Exif segment, validate the embedded TIFF header, and walk the bounded IFD0, Exif, and GPS directories.
- Review the recognized rows in the plain table. Pay particular attention to GPS latitude, longitude, and the hemisphere references that tell you whether the values are north or south of the equator and east or west of the prime meridian.
- Decide what to do with the file. If you intend to share it, strip any location fields you do not want disclosed; if you need unsupported formats, proprietary maker notes, or forensic-grade evidence, reach for a maintained desktop tool.
That five-step path is the entire workflow. The viewer does not modify the file, does not rename it, and does not write a metadata report back to disk — it only renders the values it found.
The Fields the Recognized Allowlist Covers
EXIF specifies hundreds of tags, but a portable, predictable reader focuses on the ones most cameras actually emit. The table below summarizes the common fields the viewer reports, grouped by the directory they live in. A given file may contain any subset of these rows; missing tags simply mean the camera did not write them.
| Directory | Field | What it tells you |
|---|---|---|
| IFD0 | Make / Model | The camera manufacturer and product name |
| IFD0 | Software | The application or firmware that wrote the file |
| IFD0 | Orientation | How a viewer should rotate the image for display |
| IFD0 | Pixel dimensions | Width and height in pixels |
| Exif | DateTimeOriginal / ModifyDate | Original and modified capture timestamps |
| Exif | ExposureTime | Shutter speed as a rational (for example 1/250) |
| Exif | FNumber | Aperture as a rational value |
| Exif | ISOSpeedRatings | ISO sensitivity setting |
| Exif | FocalLength | Lens focal length as a rational value |
| Exif | LensModel | The lens identifier written by the camera |
| GPS | Latitude / Longitude | Coordinates stored as DMS with N/S and E/W references |
Rational values are stored as two integers (numerator over denominator) inside the TIFF block, which is why exposure and aperture come back as fractions rather than decimals. GPS coordinates are stored as degrees, minutes, and seconds in the same rational format and need their hemisphere reference to be signed correctly: a latitude of 40 with a South reference means 40 degrees south, not north.
How the Parser Reads the File Safely
Looking under the hood helps explain why the viewer behaves the way it does. After the JPEG's SOI marker, the parser scans segment by segment until it finds an APP1 segment whose identifier spells out the Exif header. It then checks the TIFF byte order mark (II for little-endian, MM for big-endian), validates the magic number 42, and reads the offset to the first Image File Directory. From there it iterates entries: a SHORT count tells it how many tags follow, and each tag is twelve bytes — a two-byte identifier, a two-byte data type, a four-byte count, and either a four-byte inline value or an offset to longer data stored elsewhere in the segment.
At every step the parser enforces bounds. Segment lengths that would push past the end of the file are rejected. Counts that would explode into thousands of entries are rejected. Offsets that point outside the segment are rejected. Unsupported data types and proprietary maker-note blocks are skipped rather than decoded. This discipline follows the CIPA Exif 2.3 specification and is independently cross-checked against ExifTool's official tag table using eight fixture files that pin the core identifiers and types.
When a Desktop Tool Is the Right Choice
A bounded browser parser is the right tool for inspecting the common, standardized fields of a single JPEG. It is not the right tool for everything. Maker notes — the proprietary blocks written by Canon, Nikon, Sony, Apple, and others — contain rich information about focus, lens corrections, scene modes, and processing, but their layout is undocumented and changes between firmware revisions. A safe reader will not guess at their meaning. Similarly, RAW formats (CR2, NEF, ARW, RAF), HEIC, PNG, WebP, video containers, and full XMP or IPTC blocks all sit outside the JPEG Exif segment and require a more capable tool.
For those cases, ExifTool remains the reference implementation: it understands proprietary maker notes, batch-exports entire metadata inventories, preserves original files, and runs from a maintained command line. Reach for it whenever the question shifts from "what does this one JPEG say?" to "what can this image possibly say, and can I trust it as evidence?" For a deeper walkthrough of how to interpret each field after you have parsed them, see this guide to viewing EXIF data of a photo and reading each field.
Reading the GPS Block Without Oversharing
GPS metadata is the single most sensitive field a JPEG can carry. A coordinate pair recorded by a phone can place a photo within a few meters of a real address, and that location travels with the file every time it is forwarded or uploaded. The viewer converts the stored degrees-minutes-seconds values into signed decimal degrees using the hemisphere references, but the conversion is purely arithmetic — the page itself cannot decide whether the resulting location is one you are comfortable disclosing.
Before sharing a photo or a metadata report, scan the GPS rows and any embedded address-like fields. If the values are precise and you do not want them visible, remove the Exif segment before sending the file, prefer a platform that strips metadata on upload, or share a re-encoded copy. Per the CIPA Exif specification, none of these tags are required, and a file may contain none, some, or all of them — including, frustratingly for privacy purposes, only the GPS rows and nothing else.
EXIF metadata is descriptive data about a file, not proof of anything about the world the file depicts. Timestamps can be edited, cameras can be wrong, GPS locks can drift, and most social and messaging platforms strip metadata on the way to their servers. Treat the table the viewer produces as a starting point for understanding what is inside a JPEG, and reserve authoritative claims about authorship, ownership, capture time, and location for tools and processes designed for forensic work, per the metadata limits documented in the CIPA Exif 2.3 specification.