Privacy | Toolbox Guides & Articles

EXIF Metadata and Photo Privacy: What Your Images Reveal and How to Strip It

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

EXIF Metadata and Photo Privacy: What Your Images Reveal and How to Strip It

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

EXIF & Image Metadata Stripper

Load a photo to read every metadata tag it carries, then export a stripped copy. Parsing happens in browser memory, so private photos are never uploaded.

Open EXIF Viewer & Stripper →

The Data You Did Not Mean to Publish

A photograph of a whiteboard, posted to help a colleague, carries the office coordinates to five decimal places. A picture of a pet, shared on a forum, carries a home address in the same field. Neither was visible on screen, and neither was intentional.

Exif — Exchangeable Image File Format, standardised by CIPA and JEITA, currently at version 3.0 — is why. The camera writes a structured metadata block into the file at capture time, and every step afterwards copies it forward unless something explicitly removes it.

What you get from this guide: where the metadata physically lives, which fields matter for privacy, what platforms actually do with them, and how to strip them without recompressing the image.

Where the Metadata Lives

In a JPEG

A JPEG is a sequence of marker segments. Each begins with 0xFF followed by a marker byte:

Marker	Name	Contents
`FFD8`	SOI	Start of image
`FFE0`	APP0	JFIF header
`FFE1`	APP1	Exif block, or XMP packet
`FFE2`	APP2	ICC colour profile
`FFED`	APP13	IPTC / Photoshop resources
`FFDB`	DQT	Quantisation tables
`FFC0`	SOF0	Frame header (dimensions)
`FFDA`	SOS	Start of scan — the compressed pixels
`FFD9`	EOI	End of image

The key structural fact: the Exif block in APP1 is not inside the compressed scan data. It is a separate segment that a parser can skip over. That is what makes lossless stripping possible.

Inside APP1, Exif uses a TIFF-style layout: a header, then Image File Directories (IFDs) of tag entries. IFD0 holds the main image tags, IFD1 the thumbnail, and pointer tags lead to the Exif sub-IFD and the GPS IFD.

The embedded thumbnail deserves its own warning: it is a separate small JPEG stored in the metadata. If you cropped a face or a document out of a photo in some editors, the thumbnail may still show the uncropped original. Stripping metadata removes the thumbnail with it.

In a PNG

PNG is a chunk-based format. Metadata appears as ancillary chunks: eXIf for an Exif block, tEXt, zTXt, and iTXt for text pairs, tIME for modification time, and iCCP for a colour profile. Screenshots and exported graphics commonly carry the software name and timestamps here rather than GPS.

The Fields That Matter

Tag	Typical value	Privacy weight
`GPSLatitude` / `GPSLongitude`	18.5204° N, 73.8567° E	Critical — pinpoints capture location
`GPSAltitude`	13 m	High — narrows to a floor in a building
`GPSDateStamp` / `GPSTimeStamp`	UTC of the GPS fix	High — combined with location, a movement record
`DateTimeOriginal`	2026-08-14 19:42:07	High — establishes presence at a time
`OffsetTimeOriginal`	+05:30	Medium — reveals timezone
`Make` / `Model`	Apple / iPhone 17 Pro	Medium — device fingerprinting
`BodySerialNumber` / `LensSerialNumber`	Serial string	High — links every photo from one device
`Software`	Editing app and version	Low — workflow disclosure
`Artist` / `Copyright`	Photographer name	Medium — often a real legal name
`ImageUniqueID`	Per-image identifier	Medium — correlates re-shared copies
`MakerNote`	Vendor-proprietary blob	Unknown — undocumented; may hold face-detection and more

Two under-appreciated points. Serial numbers correlate: a set of “anonymous” images sharing a BodySerialNumber came from one camera, which is a strong link even without a name. And MakerNote is opaque — it is vendor-specific and undocumented, so its contents cannot be audited. Both argue for removing metadata wholesale rather than editing individual fields.

What Platforms Actually Do

Destination	Typical behaviour
Major social feeds (Instagram, Facebook, X, LinkedIn)	Re-encode uploads; the publicly served copy generally carries no Exif
Messaging apps, sent as a photo	Recompress and generally strip Exif from the delivered image
Messaging apps, sent as a file/document	Original bytes preserved — full Exif travels
Email attachments	Original bytes preserved — full Exif travels
Cloud photo services	Metadata retained by design; shared links may expose location in the UI
Your own website or CDN	Whatever you uploaded is what visitors download

Three conclusions worth internalising:

Platform stripping protects the audience, not you. The platform received the original, coordinates included, and its retention and internal access rules apply to that copy.
The “send as file” path defeats it. Choosing document instead of photo to preserve quality also preserves the entire metadata block — the most common accidental leak among people who believe they are safe because “WhatsApp strips EXIF”.
Self-hosted images are entirely your responsibility. No intermediary re-encodes an image you upload to your own site. Strip at build time.

Stripping Without Quality Loss

The wrong way is to open the image in an editor and re-export it: that decodes and re-encodes the pixels, adding a generation of JPEG loss for no reason. The right way copies the compressed scan data untouched and omits the metadata segments.

// Remove APP1 (Exif/XMP) and APP13 (IPTC) segments from a JPEG, byte-level.
// Scan data (from SOS onward) is copied verbatim: no recompression.
function stripJpegMetadata(bytes) {
 if (bytes[0] !== 0xff || bytes[1] !== 0xd8) throw new Error("Not a JPEG");
 const out = [0xff, 0xd8];
 let i = 2;

 while (i < bytes.length - 1) {
 if (bytes[i] !== 0xff) break;
 const marker = bytes[i + 1];

 // SOS: copy the remainder of the file unchanged and finish.
 if (marker === 0xda) { out.push(...bytes.slice(i)); break; }

 const len = (bytes[i + 2] << 8) | bytes[i + 3]; // includes the 2 length bytes
 const drop = marker === 0xe1 || marker === 0xed; // APP1 (Exif/XMP), APP13 (IPTC)
 if (!drop) out.push(...bytes.slice(i, i + 2 + len));
 i += 2 + len;
 }
 return new Uint8Array(out);
}

Note what this deliberately keeps: APP2, the ICC colour profile. Dropping it is not a privacy win and can visibly shift colours on wide-gamut images. Strip identity, keep rendering.

Command-line equivalents:

# exiftool: remove all metadata, no pixel re-encode
exiftool -all= photo.jpg

# Remove only location, keep exposure data for a photography portfolio
exiftool -gps:all= -xmp:geotag= photo.jpg

# Verify nothing remains
exiftool -a -G1 -s photo.jpg

The verification step is not optional. Some tools clear IFD0 but leave the GPS IFD, or clear Exif but leave an XMP packet holding the same coordinates in a different syntax.

A Practical Policy

Context	Recommended handling
Personal photos to social media	Strip all metadata before upload
Photos of your home, children, or workplace	Strip all metadata; also check the embedded thumbnail is gone
Photography portfolio	Keep exposure and lens data, remove GPS and serial numbers
Journalism or activism	Strip all metadata; assume the file will be analysed adversarially
Product images on your own site	Strip in the build pipeline, not manually
Legal or forensic evidence	Do not strip — metadata is part of the evidentiary record; preserve the original and work on copies

That last row is the exception that matters: for evidence, provenance metadata is the point, and stripping it destroys the file’s value. Everywhere else, removal is the default.

Step-by-Step: Auditing and Stripping with Toolbox

Open the tool: visit the and load a photo straight from your camera roll.
Read the GPS block first. If coordinates are present, paste them into a map to see precisely what the file discloses — this is the step that changes people’s habits.
Check the device fields: Make, Model, and any serial number, which are the tags that correlate separate images to one camera.
Strip and export. The stripped copy retains identical pixels because the compressed scan data is copied rather than re-encoded.
Re-load the stripped file in the same tool to confirm the GPS IFD, XMP packet, and embedded thumbnail are all gone — not just the main IFD.
Then compress if needed. If the image is also going to be resized or size-limited, do that after stripping using the .

Outcome: images you can publish without disclosing where they were taken, on what device, or when — with visual quality byte-identical to the original and a verification pass proving the metadata actually left.

Related guides: · ·

FAQ

Frequently Asked Questions

Does uploading a photo to Instagram or WhatsApp remove its GPS data? ▼

Major platforms re-encode uploads and generally discard EXIF from the copy they serve publicly, so a downloaded post rarely carries coordinates. But the platform still received the original including location, and sending an image as a file or document attachment rather than as a photo commonly preserves the original bytes and the full EXIF block. Strip before sharing rather than relying on the platform.

Does removing EXIF metadata reduce image quality? ▼

No, when done correctly. EXIF sits in an APP1 marker segment alongside the compressed image data, not inside it, so the segment can be dropped while the scan data is copied through untouched — a lossless operation. Quality only suffers if a tool decodes and re-encodes the image to remove metadata.

What is the difference between EXIF, XMP, IPTC, and ICC data? ▼

EXIF, standardised by CIPA and JEITA and now at version 3.0, holds camera-generated technical data including exposure, lens, timestamps, and a GPS sub-directory. XMP is Adobe's XML metadata written by editing software. IPTC carries editorial fields such as caption, creator, and copyright. ICC is a colour profile — not privacy data, but dropping it can visibly shift colours in wide-gamut images.

Can EXIF be removed from a photo I already published? ▼

Only from copies you still control. Every downloaded copy keeps what it was published with, and caches, archives, mirrors, and messaging backups may hold it indefinitely. Replace the published file with a stripped version to stop new exposure, and treat the earlier disclosure as permanent — especially where the coordinates identify a home or routine location.

Merging and Splitting PDFs Locally: File Structure, What Survives, What Breaks

Sun, 06 Sep 2026 00:00:00 +0000

Interactive Workbench LIVE

Merging and Splitting PDFs Locally: File Structure, What Survives, What Breaks

Open Fullscreen ↗

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

Free In-Browser Tool TOOLBOX UTILITY

PDF Merger & Page Combiner

Drag in multiple PDFs, order them, and export a single document. Parsing and assembly happen in browser memory, so contracts and statements are never uploaded.

Open PDF Merger →

Why PDF Editing Behaves Strangely

Most file formats are a linear stream you read from start to end. PDF is not. It is an object graph — a set of numbered objects that reference each other — plus an index telling a reader where each object lives in the file. That design is why a 400-page PDF opens instantly on page 300, and also why “deleting” a page does not necessarily delete anything.

The format is standardised as ISO 32000-1 (PDF 1.7) and ISO 32000-2:2020 (PDF 2.0). Understanding four structures explains every merge and split behaviour you will encounter.

What you get from this guide: a working mental model of the file, a checklist of what survives each operation, and the specific verification step that prevents accidentally shipping a “removed” confidential page.

The Four Structures That Matter

1. Objects

Everything is an object with a number and generation: dictionaries, arrays, numbers, strings, names, and streams (compressed binary blobs holding page content, fonts, and images).

3 0 obj
<< /Type /Page
 /Parent 2 0 R
 /MediaBox [0 0 595.28 841.89]
 /Resources << /Font << /F1 7 0 R >> >>
 /Contents 4 0 R >>
endobj

7 0 R is an indirect reference: “object 7, generation 0”. A page does not contain its font; it points at one. That indirection is the entire reason merging is cheap and also the reason resources get duplicated.

2. The cross-reference table

At the end of the file, the xref table (or, in modern files, a compressed xref stream) maps each object number to a byte offset. The trailer points to the catalog and to the xref itself:

trailer
<< /Size 12 /Root 1 0 R >>
startxref
14127
%%EOF

A reader opens a PDF by seeking to the end, reading startxref, jumping to the table, and only then loading the objects it needs.

3. The page tree

Pages are not a flat list. The catalog points to a /Pages node, which contains /Kids — pages or further nodes — and a /Count:

1 0 obj << /Type /Catalog /Pages 2 0 R >> endobj
2 0 obj << /Type /Pages /Kids [3 0 R 5 0 R 9 0 R] /Count 3 >> endobj

This is what merging and splitting actually manipulate. A merge creates a new /Pages node whose /Kids array lists page objects copied from several sources, renumbering objects to avoid collisions and rewriting every reference. A split creates a catalog whose /Kids names only the pages you kept. Page content streams are copied verbatim, which is why merging is lossless for what is drawn on the page.

4. Incremental updates

PDF allows a writer to append: leave the original bytes untouched, write changed objects at the end, and add a new xref section that supersedes the old entries. Readers follow the newest table, so the document appears edited.

The consequence is blunt: the old objects are still in the file. A page “deleted” by an incremental update can be recovered by a parser that reads the previous xref generation, and its text can sometimes be pulled out by a naive extractor that scans all streams. Redacting by drawing a black rectangle over text is the same failure in a different costume — the text object remains underneath.

What Survives Merge and Split

Element	Merge	Split	Notes
Page content (text, vectors)	✅	✅	Content streams copied byte-for-byte
Embedded fonts	✅	✅	Copied per source; often duplicated
Images / XObjects	✅	✅	Duplicated unless the library deduplicates by hash
Page size and rotation	✅	✅	`/MediaBox` and `/Rotate` are page-level
Bookmarks / outlines	⚠️	⚠️	Document-scope; frequently dropped or dangling
Internal links / named destinations	⚠️	❌	Break when the target page leaves the document
AcroForm fields	⚠️	⚠️	Field name collisions on merge; hierarchy loss on split
Digital signatures	❌	❌	Invalidated — the signed byte range no longer exists
Tags / accessibility structure	⚠️	⚠️	The `/StructTreeRoot` is document-scope; often lost
XMP / document metadata	⚠️	⚠️	Usually taken from the first input or regenerated
JavaScript actions	❌	❌	Commonly discarded

Three practical rules follow:

Sign last. Any signature applied before a merge or split is void afterwards. Assemble the document, then sign.
Flatten forms before merging. Two source files with a field named signature collide. Flattening converts fields to static page content and removes the ambiguity — at the cost of no longer being fillable.
Treat accessibility as a re-do. If the source PDFs were tagged for screen readers, verify the tag tree in the output; a merge that silently drops /StructTreeRoot produces a document that fails an accessibility audit even though it looks identical.

Doing It in the Browser

Client-side PDF assembly is genuinely practical: the page tree is a data structure, and rewriting it needs no rendering. A library such as pdf-lib parses the objects, copies pages, and serialises a new file entirely in browser memory.

import { PDFDocument } from "pdf-lib";

// MERGE: copy every page from each input into one output document.
async function mergePdfs(fileBuffers) {
 const out = await PDFDocument.create();
 for (const buf of fileBuffers) {
 const src = await PDFDocument.load(buf);
 const pages = await out.copyPages(src, src.getPageIndices());
 pages.forEach((p) => out.addPage(p));
 }
 return out.save(); // Uint8Array of the new PDF
}

// SPLIT: extract a 1-based inclusive page range.
async function extractRange(buf, from, to) {
 const src = await PDFDocument.load(buf);
 const out = await PDFDocument.create();
 const indices = Array.from({ length: to - from + 1 }, (_, k) => from - 1 + k);
 const pages = await out.copyPages(src, indices);
 pages.forEach((p) => out.addPage(p));
 return out.save();
}

copyPages performs the important work: it deep-copies each page’s referenced resources into the destination document and renumbers objects. Note what it does not do — carry over the outline tree, the form dictionary, or the structure tree. That omission is the source of most “my bookmarks vanished” reports, and it is a property of the operation rather than a bug in a particular tool.

Why local processing is the right default

A PDF you need to merge is usually a PDF you should not upload: a signed contract, a bank statement, a medical form, an ID scan. Uploading routes the document through a third party’s storage and logs, creating a retention question you cannot answer. Local assembly removes the question — with two honest limits:

Memory, not bandwidth, is the ceiling. A desktop browser handles a few hundred megabytes; a phone will fail much earlier on the same file.
Encrypted PDFs must be decrypted first. The page tree cannot be read through the encryption layer, so remove the open password in your reader before assembling.

Verifying the Output

Do not trust the page count alone. Three checks catch the failures that matter:

# 1. Structure: page count, encryption, version
pdfinfo output.pdf

# 2. Content: confirm removed text is actually gone
pdftotext output.pdf - | grep -i "confidential-term"

# 3. Size sanity: a split that removed 90% of pages should shrink accordingly
ls -l input.pdf output.pdf

Check 2 is the one people skip. If a page was removed because it held sensitive content, extracting text from the output is the only evidence that the content left with it. A result that is nearly the same size as the input, after dropping most of its pages, is a signal that objects were orphaned rather than removed.

Step-by-Step: Assembling a Document with Toolbox

Open the tool: visit the . For extracting pages, use the ; for reordering or rotating in place, the .
Remove passwords first if any input is encrypted — a protected file cannot have its page tree read.
Flatten fillable forms before merging documents that both contain form fields, to avoid field-name collisions.
Order the documents deliberately; metadata and, where preserved, the outline are typically inherited from the first input.
Export and verify: open the result, confirm the page count and page order, and if any page was dropped for confidentiality, extract the text and search for the term that mattered.
Sign or protect last, since signatures applied before assembly are invalidated by it.

Outcome: a correctly assembled document, with a deliberate decision recorded about bookmarks, forms, and signatures — and no confidential file handed to a third-party server on the way.

Related guides: · ·

FAQ

Frequently Asked Questions

Does deleting a page from a PDF actually remove its content from the file? ▼

Not necessarily. PDF supports incremental updates, where an editor appends a new cross-reference section instead of rewriting the file, so the removed page's objects can remain in the byte stream and be recoverable. Only a full rewrite drops orphaned objects, so verify that the output shrank as expected and re-extract text from the result before distributing it.

Why is my merged PDF larger than the sum of its inputs? ▼

Resources are duplicated rather than shared. Each source carries its own embedded font subsets, colour profiles, and image XObjects, and a naive merge copies all of them, so two files embedding the same font subset produce a doubled result. Some libraries deduplicate identical streams by hash; many do not. Recompressing or re-subsetting fonts recovers most of the size.

What is lost when a PDF is split into separate pages? ▼

Anything defined at document scope. Bookmarks pointing outside the extracted range become dangling and are usually dropped, internal links break, AcroForm hierarchies can lose shared fields, JavaScript and named destinations are often discarded, and digital signatures are invalidated because the signed byte range no longer exists. Page content, embedded fonts, and vector graphics survive.

Can a browser-based tool handle a large or encrypted PDF? ▼

Size is limited by available memory rather than an upload cap, so hundreds of megabytes usually work on a desktop while mobile browsers fail earlier. Encryption is a hard limit: the page tree cannot be read through the encryption layer, so remove the password in your PDF reader before merging or splitting.

How to Compress Images to 100KB, 200KB, or 500KB Online (Without Quality Loss)

Fri, 04 Sep 2026 00:00:00 +0000

Free In-Browser Tool TOOLBOX UTILITY

Compress Image to Exact Target Size

Select your target size (50KB, 100KB, 200KB, 500KB) and compress photos instantly in memory with zero quality degradation.

Compress Image to 200KB Now →

Why Exact File Size Compression Matters

Whether applying for government examinations, university admissions portals, visa applications, or optimizing web performance for Google Core Web Vitals, rigid file size limits are ubiquitous:

Passport & Visa Portals: Frequently reject photos larger than 200KB or 100KB.
Job Applications & KYC Systems: Restrict ID card scans to 500KB.
Mobile Web Performance: Keeping hero images under 150KB is vital for passing Largest Contentful Paint (LCP) benchmarks.

Traditional image editors only offer arbitrary “Quality 80%” sliders without showing the final byte count until after you export.

How In-Browser Target-Size Compression Works

In-browser tools achieve exact target sizes without server round-trips through a combination of the FileReader API, HTML5 Canvas, and Binary Search Quantization:

graph TD UserFile[User Selects Image File] --> MemoryLoad[Loaded into Local Memory via URL.createObjectURL] MemoryLoad --> CanvasRender[Rendered onto In-Memory HTML5 Canvas] CanvasRender --> BinarySearch[Binary Search Quantization Loop: min=0.0, max=1.0] BinarySearch --> BlobCheck{toBlob Output <= Target?} BlobCheck -->|Too Large| LowerQuality[Reduce Max Bound: quality = mid] BlobCheck -->|Too Small| RaiseQuality[Increase Min Bound: quality = mid] BinarySearch --> Converged[Target Met in 6-8 Iterations] Converged --> Download[Instant Zero-Latency Download]

The Binary Search Algorithm in Action:

Initialize Range: minQuality = 0.01, maxQuality = 1.0.
Evaluate Midpoint: currentQuality = (minQuality + maxQuality) / 2.
Generate Blob: canvas.toBlob(blob => ..., 'image/jpeg', currentQuality).
Compare Bytes:
- If blob.size > targetBytes: The quality is too high. Set maxQuality = currentQuality.
- If blob.size <= targetBytes: Record this as the best candidate. Set minQuality = currentQuality.
Terminate: After 6–8 iterations, the algorithm identifies the optimal visual quality that strictly satisfies the size constraint.

Format Efficiency: JPEG vs WebP vs PNG

Metric	JPEG	WebP (Recommended)	PNG
Compression Type	Lossy DCT	Lossy VP8 / Lossless	Lossless DEFLATE
Typical Size at 200KB Quality	Baseline standard	~30% sharper than JPEG	Unsuitable for photos
Alpha Transparency	❌ Not supported	✅ Fully supported	✅ Fully supported
Browser Support	100%	> 97% modern browsers	100%
Best Use Case	Legacy portal uploads	Modern web graphics & photos	Logos, icons, charts

Privacy Advantage: Zero Network Transmission

Uploading scanned driver’s licenses, passports, or tax forms to unknown server-side image compression services presents substantial identity theft risks. Server-side tools frequently write incoming images to disk caches or upload them to third-party cloud buckets.

Because executes strictly in your browser’s local sandbox:

Your files never touch any external server.
No network requests are made during compression.
Closing the tab immediately purges the memory allocation.

Interactive Workbench LIVE

Compress Images to 100KB, 200KB, or 500KB Online (Without Quality Loss)

Open Fullscreen ↗

Select your target size (50KB, 100KB, 200KB, 500KB) and compress photos instantly in memory with zero quality degradation.

Initializing Workbench...

100% Client-Side RAM Sandbox

🔒 Private Execution: Computations run in local browser memory. Zero server uploads. Zero server uploads.

Launch Fullscreen →

FAQ

Frequently Asked Questions

How does in-browser image compression achieve an exact file size like 200KB? ▼

Client-side image tools draw your uploaded image onto an in-memory HTML5 Canvas and run a binary search algorithm across compression quality levels (0.01 to 1.0). In 6 to 8 iterations, the tool converges on the exact quality float that yields a blob size just under your target threshold.

Is my photo uploaded to any server during compression? ▼

No. The entire decoding, resizing, canvas rendering, and re-encoding process happens within your browser's local sandbox memory. No file data or network packets are sent to remote servers.

Should I compress images to WebP or JPEG for the best quality-to-size ratio? ▼

WebP provides approximately 25% to 34% better compression efficiency compared to standard JPEG at equivalent visual quality. For strict portal uploads requiring JPEG, use standard JPEG format; for web performance, select WebP.