DEV Community: Sanjoy Karmakar

What is EXIF data, and how do you remove it from a photo?

Sanjoy Karmakar — Wed, 15 Jul 2026 08:56:08 +0000

Every photo your phone or camera takes carries an invisible passenger: EXIF data. It rides along inside the file, adds nothing to what you see on screen, and can quietly tell a stranger where you were standing when you took the picture. Here's what EXIF data actually is, what it can reveal, and how to strip it before you share a photo.

What is EXIF data, exactly?

EXIF stands for Exchangeable Image File Format — a standard, maintained by the Camera & Imaging Products Association (CIPA), for embedding a block of metadata inside a JPEG photo. When a digital camera or phone saves a JPEG, it writes a small binary block right after the start of the file (technically, an APP1 segment structured like a miniature TIFF file) containing tags about the shot: not the pixels, but facts about the pixels.

It's not a hack or a leak in the traditional sense — EXIF was designed to be there. The problem is that almost nobody ever looks at it before hitting send.

What's actually inside an EXIF block

A camera can write dozens of EXIF fields, but the ones that matter for privacy are a short list:

Field	What it reveals
`Make` / `Model`	The exact phone or camera model that took the photo
`Software`	The app or firmware version used to process it
`DateTime` / `DateTimeOriginal`	When the photo was taken and last saved, to the second
`Artist` / `Copyright`	A name, if the device or app was configured with one
`Orientation`	Which way to rotate the image for display
`ExposureTime` / `FocalLength`	Camera settings — not private, but confirms real gear was used
`GPSLatitude` / `GPSLongitude`	The exact location the photo was taken, often to within a few metres

That last one is the field that actually causes harm. GPS coordinates baked into a photo are precise enough to point at a front door, a workplace, or a child's school — from a single JPEG, with no other information needed.

The Orientation tag is worth a specific mention because it's the one EXIF field browsers already act on: the CSS image-orientation property's default value, from-image, tells the browser to auto-rotate a JPEG using this exact tag — proof that EXIF isn't some obscure forensic curiosity, it's live metadata your own browser reads today.

How to see what your photo is carrying

You don't have to take any of this on faith — you can look. FileX's Inspect tool reads a JPEG's EXIF block and lists every tag it finds, including a specific warning if GPS coordinates are present, before you decide to share anything. It's read-only: nothing is written back to the file, and because it runs entirely in your browser, the photo itself never leaves your device just to be checked.

How to remove EXIF data from a photo

Once you know what's there, removing it is one step: FileX's Scrub tool takes a JPG or PNG and re-encodes it as a fresh JPEG at 95% quality, using the browser's <canvas> element. That re-encode is the whole mechanism — a canvas only ever knows about pixels, so when it redraws your photo it has no way to carry the old EXIF block along. The output is visually identical, full resolution, same content — just without the metadata that came in.

Two things worth knowing about that process:

It always produces a JPEG, even if you dropped in a PNG. If your source was a PNG with embedded metadata, re-encoding still discards it.
Because it's a genuine re-encode at high quality (not a lossless strip), there's no meaningful visible quality loss, but it isn't a bit-for-bit copy of the original either.

Does resizing or cropping remove EXIF automatically?

Not necessarily — plenty of photo editors preserve the EXIF block when they resize or crop, because they write the new pixels back into the same container without touching the metadata section. The only way to be sure is to either check with a tool like Inspect, or use a tool that explicitly re-encodes through a metadata-blind path like canvas — which is exactly what removes it here.

A quick before-you-send checklist

Selling something online? Product photos taken at home routinely carry GPS. Scrub before you post the listing.
Sharing photos from an event or trip? Timestamps and device model are low-risk alone, but combined with GPS they build a fuller picture than most people intend to share.
Sending a photo to someone you don't fully trust? Inspect first — it takes seconds and costs nothing to know.

EXIF is only half the metadata story — PDFs and other documents carry their own hidden properties (author names, software fingerprints, timestamps), which works a little differently. The deeper look at hidden metadata covers both photos and documents side by side if you want the fuller picture.

Curious what your own photos are carrying? Drop one into the Inspect tool — it's free, read-only, and nothing is uploaded.

How to securely erase an SSD (and why overwriting isn't enough)

Sanjoy Karmakar — Fri, 10 Jul 2026 09:35:35 +0000

If you're about to sell, return, or recycle a laptop, the instinct is to delete your files, maybe run an overwrite tool, and call it done. On a spinning hard drive that instinct is basically correct. On a solid-state drive (SSD) — which is what's inside almost every laptop sold today — it isn't. You can securely erase an SSD, but not by overwriting files in place. Here's why, and what actually works.

Why file overwrites don't reliably erase an SSD

Overwriting a file writes new bytes over the old ones so the original content is physically replaced — that's real erasure, and it's exactly what an in-browser eraser tool does. The catch is what "in place" means on flash storage.

An SSD can't rewrite a single cell the way a magnetic platter can. To spread physical wear evenly and stay fast, SSD controllers use wear-leveling: when your OS "overwrites" a file, the controller frequently parks the new data in a different physical location and retires the old block instead of erasing it there. The filesystem reports success. The original bytes may still exist in a block the OS can no longer even address. We cover this mechanism — and the related myth that more overwrite passes helps — in more depth in does deleting a file actually erase it?

The upshot: a software overwrite on an SSD is a best-effort logical wipe. It defeats undelete and file-recovery tools, which is the level NIST calls "Clear." It cannot promise a lab with the right equipment won't recover a fragment from a retired block. For most everyday deletions, Clear is genuinely enough. For a drive that's about to leave your hands entirely, it usually isn't.

The reference standard: NIST SP 800-88

NIST Special Publication 800-88, "Guidelines for Media Sanitization," defines the escalating levels that matter here:

Level	What it does	Defeats
Clear	Overwrite user-addressable storage with new data	Standard undelete / recovery software
Purge	Techniques that resist laboratory recovery — cryptographic erase, or the drive's own firmware sanitize command	Forensic recovery
Destroy	Physical destruction of the media	Everything

A whole SSD you're decommissioning calls for Purge, not Clear. NIST 800-88 lists two practical ways to get there on flash media:

Cryptographic erase — if the drive (or a volume on it) was encrypted, destroying the encryption key instantly makes every block unreadable, no matter which physical location the controller actually wrote to. This is the fastest and most broadly applicable Purge method for SSDs, provided encryption was on from the start.
The drive's own sanitize / secure-erase command — issued directly to the controller (ATA Secure Erase for SATA drives, NVMe Sanitize for NVMe drives). The firmware erases the flash itself, which is the one layer that isn't fooled by wear-leveling, because it operates below it.

Both require access a web browser simply doesn't have — this is OS- and firmware-level work, not something JavaScript running in a tab can issue.

What that actually looks like

Concretely, reaching Purge on a real machine means one of:

Linux, LUKS-encrypted drive: destroy the volume key (cryptsetup luksErase) for an instant crypto-erase.
Linux, NVMe: issue an NVMe Sanitize block-erase (nvme sanitize) — the drive's firmware wipes itself.
Linux/any OS, SATA SSD: the drive's ATA Security Erase Unit command (often run via hdparm --security-erase).
macOS: disable FileVault and destroy the APFS volume key for a crypto-erase, or use the drive's native secure-erase utility.
Windows: turn off BitLocker and reformat to destroy the key, or run the drive vendor's secure-erase tool.

These are irreversible, whole-device operations — exactly the kind of thing that shouldn't run silently or by accident, and exactly why FileX draws a hard line around them.

Where FileX's two erasure tools fit

FileX ships two erasure tools, and each is honest about which level it reaches:

The in-browser Eraser overwrites and deletes the contents of a folder you choose, entirely in your browser via the File System Access API — nothing leaves your device. That's Clear: it reliably defeats recovery software, and it's the right tool for cleaning out sensitive files you're done with day to day. It is not, and doesn't claim to be, a whole-drive Purge tool — a browser tab can't touch drive firmware.

The downloadable FileX Eraser Tool (native, Windows/macOS/Linux, Pro-licensed) also supports crypto-erase and purge methods for whole devices. Deliberately, it does not fire the firmware sanitize command itself — that's a destructive, irreversible action on an entire disk, and an unsigned CLI shouldn't auto-execute it. Instead it detects your OS and prints the correct, vetted native command for your platform (nvme sanitize, hdparm --security-erase, cryptsetup luksErase, diskutil secureErase, or the BitLocker equivalent) so you run it deliberately, as an admin, against the right device. For file- and folder-level clear jobs it runs the erase itself and produces the same tamper-evident certificate as the web tool.

The practical takeaway

Deleting or even overwriting individual files on an SSD is Clear-level protection — good for day-to-day cleanup, not a guarantee for hardware leaving your control.
The reliable way to reach Purge on an SSD is cryptographic erase (destroy the key) or the drive's own ATA Secure Erase / NVMe Sanitize command — both need OS- or firmware-level access.
Turn on full-disk encryption from day one on any drive you might ever resell or return. It makes a future crypto-erase instant instead of impossible.
For files you want gone right now, not a whole drive, the in-browser Eraser overwrites and deletes them locally and hands you a certificate — nothing uploaded.

PBKDF2 vs Argon2 vs bcrypt — which key-derivation function and why

Sanjoy Karmakar — Wed, 08 Jul 2026 09:20:39 +0000

If you've read anything about password hashing or encryption, you've run into all three names: PBKDF2, bcrypt, Argon2. They get lumped together as "ways to turn a password into something safe to store or use," but they were built for different problems, at different times, and they don't defend against the same attacks equally well. Here's what each one actually does, where they diverge, and why FileX derives its encryption keys with PBKDF2 rather than the others.

What a key-derivation function is for

A password like correct horse battery staple is not usable directly as a cryptographic key, and it's not safe to check by comparing it to a plain stored copy either. A key-derivation function (KDF) — sometimes called a password-hashing function in the login context — takes the password plus a random salt and runs it through a deliberately expensive one-way computation. Two properties matter:

The salt makes every derivation unique, even for two people who pick the same password, so an attacker can't precompute one giant table of results and reuse it against every target.
The cost (iterations, memory, or both) makes each guess slow. An attacker who steals a salt and a ciphertext (or a stored hash) still has to pay that cost for every single password they try. That's the entire point — the cipher or the login check is rarely the weak link; how expensive it is to brute-force the password is.

PBKDF2, bcrypt, and Argon2 all satisfy this shape. Where they differ is what they make expensive.

PBKDF2: CPU-hard, standardized, everywhere

PBKDF2 (Password-Based Key Derivation Function 2) dates to 2000 and is specified in RFC 2898. It derives a key by running an underlying HMAC (commonly HMAC-SHA256) over the password and salt thousands of times in sequence. The only cost knob is iterations — more repetitions, more CPU time, no memory requirement beyond the hash itself.

That single-dimension cost is PBKDF2's main weakness: it parallelizes cleanly on GPUs and ASICs, which can run huge numbers of hash iterations concurrently far cheaper than a general-purpose CPU can. NIST SP 800-63B sets the floor at "typically at least 10,000 iterations," while the current OWASP Password Storage Cheat Sheet recommends 600,000 iterations for PBKDF2-HMAC-SHA256 in new systems specifically because commodity GPU cracking has gotten so much faster since the function was designed. PBKDF2 is still considered sound — it just needs a high, regularly-revisited iteration count to stay expensive against modern hardware.

bcrypt: built for login checks, not general key derivation

bcrypt (1999) wraps the Blowfish cipher into a password-hashing scheme with a configurable, exponential cost factor. It was a real improvement over unsalted or fast-hashed passwords at the time, and OWASP still lists it as an acceptable choice with a work factor "as large as verification server performance will allow, with a minimum of 10."

Two things limit it outside login-check use cases: it silently truncates input past 72 bytes, and — like PBKDF2 — its cost is CPU time only, so it doesn't resist a well-funded, memory-rich cracking rig as well as a memory-hard function does. It's also not part of any Web Crypto API standard, so a browser can't produce it without shipping a separate implementation.

Argon2: memory-hard, the modern default

Argon2 won the Password Hashing Competition in 2015 and is standardized in RFC 9106. Its cost has three independent dials: iterations (time), memory (how much RAM each computation must hold), and parallelism. That memory requirement is the important change — a GPU or ASIC that can run millions of cheap hash operations in parallel can't cheat past a function that demands, say, 19 MiB of memory per guess. Memory is expensive to parallelize at scale in a way that raw compute isn't.

OWASP now recommends Argon2id (a hybrid variant resistant to both side-channel and GPU-style attacks) as the first choice for new password-hashing systems, falling back to PBKDF2 only when FIPS-140 compliance is required.

The three, side by side

	PBKDF2	bcrypt	Argon2id
Defined	RFC 2898 (2000)	1999, no formal RFC	RFC 9106 (2021)
Cost dimension	Iterations (CPU only)	Cost factor (CPU only)	Time + memory + parallelism
GPU/ASIC resistance	Weaker — parallelizes well	Moderate	Strong when memory is tuned high
Input limits	None significant	Truncates past 72 bytes	None significant
Native in the browser (Web Crypto API)	Yes	No	No
FIPS-140 status	Approved	Not a NIST/FIPS algorithm	Not currently FIPS-approved

Why FileX uses PBKDF2

FileX derives the AES-256 key for every .filex container with PBKDF2-HMAC-SHA256, a random 16-byte salt, and 250,000 iterations, calling crypto.subtle.deriveKey directly — the Web Crypto API built into every modern browser. That's the deciding factor: SubtleCrypto.deriveKey supports PBKDF2, HKDF, and ECDH natively. It does not support Argon2 or bcrypt. Getting either of those into the browser means shipping a third-party WebAssembly implementation and trusting it the way you'd trust any dependency — which cuts against FileX's rule of using only the browser's own audited, self-hosted crypto primitives with nothing extra to fetch or verify.

That's an honest trade-off, not a claim that PBKDF2 is the strongest KDF available. Argon2id's memory-hardness is a genuine advantage against large-scale GPU cracking, and if you're designing a server-side login system today, OWASP's guidance to prefer Argon2id over PBKDF2 is worth following. FileX's use case is different in one respect but not immune to the same math: it derives a file encryption key from a password, not a login-check hash, but an attacker who obtains a .filex file still faces the same offline brute-force economics — the salt and iteration count are exactly what slow them down. FileX's 250,000 iterations sit well above the NIST floor of 10,000, though below OWASP's newer 600,000-iteration figure for stored password verifiers; iteration counts are a moving target as hardware gets faster, which is why the cheat sheets keep raising them.

The practical upshot for you: the KDF is only half the defense. A long, random password does more for your file's security than any iteration count can compensate for on its own — generate one in your browser with the same zero-upload guarantee. For the full picture of how the derived key gets used — AES-256-GCM, the random IV, the authentication tag that rejects tampering — see how AES-256-GCM keeps your files safe.

Takeaway

All three — PBKDF2, bcrypt, Argon2 — exist to make password guessing slow, not to make encryption itself stronger.
PBKDF2 and bcrypt cost CPU time only; Argon2 also costs memory, which is why it resists GPU/ASIC cracking better.
Web browsers only implement PBKDF2 natively (via the Web Crypto API), which is why FileX — and most in-browser crypto — uses it rather than Argon2 or bcrypt.
The password you choose still matters more than the KDF choice. Encrypt a file in your browser — nothing is uploaded, and the live monitor on the page proves it.