about · this thing

Why this exists.

Most EXIF tools want you to upload your photos to a stranger's server, which is total bullshit considering it can be done in the browser. Cameras embed decades of metadata in every shot — shutter, aperture, GPS, lens, firmware, even the serial number of the body. You shouldn't have to hand that to a SaaS to read it.

So we compiled an EXIF parser to WebAssembly, and stuffed it into this terrible website. Your files stay on your machine. The parser runs next to them. Nothing makes a round trip.

Spec sheet

Engine

WebAssembly

Workers

Parallel pool, tuned to your machine

Servers

zero

Accounts

none, ever

Tracking

How it works

STEP 01

Drop files

Files go onto the pad via drag-drop, click, or folder-pick. Browser fills an ArrayBuffer in memory.

STEP 02

Queue files

JS spawns workers. Each worker owns a WASM instance. Files get distributed round-robin.

STEP 03

Parse files

The WASM module reads the file header, walks EXIF IFDs, lifts tags, pulls the embedded thumbnail if present.

STEP 04

Render results

Parsed records stream back to the main thread and into the file list. Raw JSON kept next to each.

Questions we get

The folder dialog says "upload" — is it uploading?

No. That is the browser being overly cautious. The files are never uploaded. We only read them in memory. No network call is made. You can disconnect your internet and it will still work.

How big a folder can I throw at it?

Tested up to many thousands of photos. The bottleneck is disk read, not parse. Memory stays flat because we stream files through the workers one at a time.

Does it read GPS?

Yes — when present. It will not geocode it for you; we do not talk to a map provider.

Why is it called CR3 Viewer?

Because it was the first version of the app, no one else was doing it, and it was built to view CR3 files. It has since been expanded to support more formats. We may change the name in the future.