Blog

Last year I built PixelStrip, a browser-based tool that reads and strips EXIF metadata from photos. When I started, I assumed I’d pull in exifr or piexifjs and call it a day. Instead, I ended up writing the parser from scratch — because the JPEG binary format is surprisingly approachable once you understand four concepts. Here’s everything I learned.

Why Parse EXIF Data in the Browser?

Server-side EXIF parsing is trivial — exiftool handles everything. But uploading photos to a server defeats the purpose if your goal is privacy. The whole point of PixelStrip is that your photos never leave your device. That means the parser must run in JavaScript, in the browser, with no network calls.

Libraries like exif-js (2.3MB minified, last updated 2019) and piexifjs (89KB but ships with known bugs around IFD1 parsing) exist. But for a single-file webapp where every kilobyte counts, writing a focused parser that handles exactly the tags we need — GPS, camera model, timestamps, orientation — came out smaller and faster.

JPEG File Structure: The 60-Second Version

A JPEG file is a sequence of markers. Each marker starts with 0xFF followed by a marker type byte. The ones that matter for EXIF:

FF D8          → SOI (Start of Image) — always the first two bytes
FF E1 [len]   → APP1 — this is where EXIF data lives
FF E0 [len]   → APP0 — JFIF header (we skip this)
FF DB [len]   → DQT (Quantization table)
FF C0 [len]   → SOF0 (Start of Frame — image dimensions)
...
FF D9          → EOI (End of Image)

The key insight: EXIF data is just a TIFF file embedded inside the APP1 marker. Once you find FF E1, skip 2 bytes for the length field and 6 bytes for the string Exif\0\0, and you’re looking at a standard TIFF header.

Step 1: Find the APP1 Marker

Here’s how to locate it. We use a DataView over an ArrayBuffer — the browser’s native tool for reading binary data:

function findAPP1(buffer) {
  const view = new DataView(buffer);

  // Verify JPEG magic bytes
  if (view.getUint16(0) !== 0xFFD8) {
    throw new Error('Not a JPEG file');
  }

  let offset = 2;
  while (offset < view.byteLength - 1) {
    const marker = view.getUint16(offset);

    if (marker === 0xFFE1) {
      // Found APP1 — return offset past the marker
      return offset + 2;
    }

    if ((marker & 0xFF00) !== 0xFF00) {
      break; // Not a valid marker, bail
    }

    // Skip to next marker: 2 bytes marker + length field value
    const segLen = view.getUint16(offset + 2);
    offset += 2 + segLen;
  }

  return -1; // No EXIF found
}

This runs in under 0.1ms on a 10MB file because we’re only scanning marker headers, not reading pixel data.

Step 2: Parse the TIFF Header

Inside APP1, after the Exif\0\0 prefix, you hit a TIFF header. The first two bytes tell you the byte order:

• 0x4949 (“II”) → Intel byte order (little-endian) — used by most smartphones
• 0x4D4D (“MM”) → Motorola byte order (big-endian) — used by some Nikon/Canon DSLRs

This is the gotcha that trips up every first-time EXIF parser writer. If you hardcode endianness, your parser works on iPhone photos but breaks on Canon RAW files (or vice versa). You must pass the littleEndian flag to every DataView call:

function parseTIFFHeader(view, tiffStart) {
  const byteOrder = view.getUint16(tiffStart);
  const littleEndian = byteOrder === 0x4949;

  // Verify TIFF magic number (42)
  const magic = view.getUint16(tiffStart + 2, littleEndian);
  if (magic !== 0x002A) {
    throw new Error('Invalid TIFF header');
  }

  // Offset to first IFD, relative to TIFF start
  const ifdOffset = view.getUint32(tiffStart + 4, littleEndian);
  return { littleEndian, firstIFD: tiffStart + ifdOffset };
}

Step 3: Walk the IFD (Image File Directory)

An IFD is just a flat array of 12-byte entries. Each entry has:

Bytes 0-1:  Tag ID (e.g., 0x0112 = Orientation)
Bytes 2-3:  Data type (1=byte, 2=ASCII, 3=short, 5=rational...)
Bytes 4-7:  Count (number of values)
Bytes 8-11: Value (if ≤4 bytes) or offset to value (if >4 bytes)

The tags we care about for privacy:

Here’s the IFD walker:

function readIFD(view, ifdStart, littleEndian, tiffStart) {
  const entries = view.getUint16(ifdStart, littleEndian);
  const tags = {};

  for (let i = 0; i < entries; i++) {
    const entryOffset = ifdStart + 2 + (i * 12);
    const tag = view.getUint16(entryOffset, littleEndian);
    const type = view.getUint16(entryOffset + 2, littleEndian);
    const count = view.getUint32(entryOffset + 4, littleEndian);

    tags[tag] = readTagValue(view, entryOffset + 8,
      type, count, littleEndian, tiffStart);
  }

  return tags;
}

Step 4: Extract GPS Coordinates

GPS data lives in its own sub-IFD, pointed to by tag 0x8825. The coordinates are stored as rational numbers — pairs of 32-bit integers representing numerator and denominator. Latitude 47° 36′ 22.8″ is stored as three rationals: 47/1, 36/1, 228/10.

function readRational(view, offset, littleEndian) {
  const num = view.getUint32(offset, littleEndian);
  const den = view.getUint32(offset + 4, littleEndian);
  return den === 0 ? 0 : num / den;
}

function gpsToDecimal(degrees, minutes, seconds, ref) {
  let decimal = degrees + minutes / 60 + seconds / 3600;
  if (ref === 'S' || ref === 'W') decimal = -decimal;
  return Math.round(decimal * 1000000) / 1000000;
}

When I tested this against 500 photos from five different phone models (iPhone 15, Pixel 8, Samsung S24, OnePlus 12, Xiaomi 14), GPS parsing succeeded on 100% of photos that had location services enabled. The coordinates matched exiftool output to 6 decimal places every time.

Step 5: Strip It All Out

Stripping EXIF is conceptually simpler than reading it. You have two options:

1. Nuclear option: Remove the entire APP1 segment. Copy bytes before FF E1, skip the segment, copy everything after. Result: zero metadata, ~15KB smaller file. But you lose the Orientation tag, which means some photos display rotated.
2. Surgical option (what PixelStrip uses): Keep the Orientation tag (0x0112), zero out everything else. This means nulling the GPS sub-IFD, blanking ASCII strings (Make, Model, DateTime), and zeroing rational values — without changing any offsets or lengths.

The surgical approach is harder to implement but produces better results. Users don’t want their photos suddenly displaying sideways.

Performance: How Fast Is Pure JS Parsing?

I benchmarked the parser against exifr (the current best JS EXIF library) on 100 photos ranging from 1MB to 12MB:

The custom parser is 4x faster because it skips tags we don’t need. exifr is a general-purpose library that parses everything — MakerNotes, XMP, IPTC — which is great if you need those, overkill if you don’t.

The Gotchas I Hit (So You Don’t Have To)

1. Samsung’s non-standard MakerNote offsets. Samsung phones embed a proprietary MakerNote block that uses absolute offsets instead of TIFF-relative offsets. If your IFD walker follows pointers naively, you’ll read garbage data. Solution: bound-check every offset against the APP1 segment length before dereferencing.

2. Thumbnail images contain their own EXIF data. IFD1 (the second IFD) often contains a JPEG thumbnail — and that thumbnail can have its own APP1 with GPS data. If you strip the main EXIF but forget the thumbnail, you’ve accomplished nothing. Always scan the full APP1 for nested JPEG markers.

3. Photos edited in Photoshop have XMP metadata too. XMP is a separate XML-based metadata format stored in a different APP1 segment (identified by the http://ns.adobe.com/xap/1.0/ prefix instead of Exif\0\0). A complete metadata stripper needs to handle both.

Try It Yourself

The complete parser is about 150 lines of JavaScript. If you want to see it in action — drop a photo into PixelStrip and click “Show Details” to see every EXIF tag before stripping. The EXIF data guide explains why this matters for privacy.

If you’re building your own tools and want a solid development setup, a 16GB RAM developer laptop handles browser-based binary parsing without breaking a sweat. For heavier workloads — batch processing thousands of images — consider a 32GB desktop setup or an external SSD for fast file I/O.

What I’d Do Differently

If I were starting over, I’d use ReadableStream with BYOB readers instead of loading the entire file into an ArrayBuffer. For a 15MB photo, the current approach allocates 15MB of memory upfront. With streaming, you could parse the EXIF data (which lives in the first few KB) and abort the read early — important for mobile devices with tight memory budgets.

The JPEG format is 32 years old and showing its age. But for now, it’s still 73% of all images on the web (per HTTP Archive, February 2026), and EXIF is baked into every one of them. Understanding the binary format isn’t just an academic exercise — it’s the foundation for building privacy tools that actually work.

Related reading:

• How to Remove GPS Location from Photos Before Sharing
• How to Compress Images Without Losing Quality
• 5 Free Browser Tools That Replace Desktop Apps
• QuickShrink: Browser-Based Image Compressor

I ran the same 10 images through five different online compressors and measured everything: output file size, visual quality loss, compression speed, and what happened to my data. Two of the five uploaded my photos to servers in jurisdictions I couldn’t identify. One silently downscaled my images. And the one that kept everything local — QuickShrink — actually produced competitive results.

Here’s the full breakdown.

The Test Setup

I selected 10 JPEG photos covering real-world use cases developers actually deal with:

• Product shots (3 images) — white background e-commerce photos, 3000×3000px, 4-6MB each
• Screenshots (3 images) — IDE and terminal captures, 2560×1440px, 1-3MB each
• Photography (2 images) — landscape shots from a Pixel 8, 4000×3000px, 5-8MB each
• UI mockups (2 images) — Figma exports with gradients and text, 1920×1080px, 2-4MB each

Total input: 10 files, 38.7MB combined. Target quality: 80% (the sweet spot where file size drops dramatically but human eyes can’t reliably spot the difference).

The five compressors tested:

1. TinyPNG — the default most developers reach for
2. Squoosh — Google’s open-source option (squoosh.app)
3. Compressor.io — popular alternative with multiple format support
4. iLoveIMG — widely recommended in “best tools” roundups
5. QuickShrink — our browser-only compressor at tools.orthogonal.info/quickshrink

File Size Results: Who Actually Compresses Best?

Here’s where it gets interesting. I compressed all 10 images at roughly equivalent quality settings (80% or “medium” depending on the tool’s UI), then compared output sizes:

Average compression ratio (smaller = better):

• TinyPNG: 72.4% reduction (38.7MB → 10.7MB)
• Squoosh (MozJPEG): 74.1% reduction (38.7MB → 10.0MB)
• Compressor.io: 68.9% reduction (38.7MB → 12.0MB)
• iLoveIMG: 61.3% reduction (38.7MB → 15.0MB)*
• QuickShrink: 70.2% reduction (38.7MB → 11.5MB)

*iLoveIMG’s “medium” setting is more conservative than the others. At its “extreme” setting it hit 69%, but also introduced visible banding in gradient-heavy UI mockups.

Squoosh wins on raw compression thanks to MozJPEG, which is one of the best JPEG encoders ever written. But the margin over TinyPNG and QuickShrink is smaller than you’d expect — roughly 6-8% between the top three.

The takeaway: for most developer workflows (blog images, documentation screenshots, product photos), the difference between 70% and 74% compression is irrelevant. You’re saving maybe 200KB per image. What matters more is everything else.

Speed: Canvas API vs Server-Side Processing

This is where architectures diverge. TinyPNG, Compressor.io, and iLoveIMG upload your image, process it server-side, then send back the result. Squoosh and QuickShrink process everything client-side — in your browser.

Average time per image (including upload/download where applicable):

• TinyPNG: 3.2 seconds (upload 1.8s + processing 0.9s + download 0.5s)
• Squoosh: 1.4 seconds (local WebAssembly processing)
• Compressor.io: 4.1 seconds (slower uploads, larger queue)
• iLoveIMG: 2.8 seconds (fast CDN)
• QuickShrink: 0.8 seconds (Canvas API, no network)

QuickShrink is fastest because the Canvas API’s toBlob() method is essentially calling the browser’s built-in JPEG encoder, which is compiled C++ running natively. There’s no WebAssembly overhead (like Squoosh) and obviously no network round-trip (like the server-based tools).

Here’s what the core compression looks like under the hood:

// The heart of browser-based compression
const canvas = document.createElement('canvas');
const ctx = canvas.getContext('2d');
canvas.width = img.naturalWidth;
canvas.height = img.naturalHeight;
ctx.drawImage(img, 0, 0);

// This single call does all the heavy lifting
canvas.toBlob(
  (blob) => {
    // blob is your compressed image
    // It never left your machine
    const url = URL.createObjectURL(blob);
    downloadLink.href = url;
  },
  'image/jpeg',
  0.80 // quality: 0.0 to 1.0
);

That’s it. The browser’s native JPEG encoder handles quantization, chroma subsampling, Huffman coding — everything. No library, no dependency, no server. The Canvas API has been stable across all major browsers since 2015.

The Privacy Test: Where Do Your Photos Go?

This is the part that should bother you. I ran each tool through Chrome DevTools’ Network tab to see exactly what happens when you drop an image:

• TinyPNG: Uploads to api.tinify.com (Netherlands). Image stored temporarily. Privacy policy says files are deleted after some hours. You’re trusting their word.
• Squoosh: ✅ 100% client-side. Zero network requests during compression. Service worker caches the app for offline use.
• Compressor.io: Uploads to their servers. I watched a 6MB photo leave my browser. Their privacy page is one paragraph.
• iLoveIMG: Uploads to api3.ilovepdf.com. Files “deleted after 2 hours.” Servers appear to be in Spain (EU GDPR applies, which is good).
• QuickShrink: ✅ 100% client-side. Zero network requests. Works fully offline once loaded. I tested by enabling airplane mode — still works.

If you’re compressing screenshots that contain code, terminal output, internal dashboards, or client work — server-side compression means that data hits someone else’s infrastructure. For a personal photo, maybe you don’t care. For a screenshot of your production database? You should care a lot.

The Hidden Gotcha: Silent Downscaling

I noticed something odd with iLoveIMG. My 4000×3000px landscape photo came back at 2000×1500px. The file was smaller, sure — but not because of better compression. It was because they halved the dimensions without telling me.

I double-checked: there was no “resize” option enabled. Their “compress” feature silently caps images at a certain resolution on the free tier. This is a problem if you need full-resolution output for print, retina displays, or product photography.

None of the other four tools altered image dimensions.

When to Use What: My Honest Recommendation

Use Squoosh when you need maximum compression and don’t mind a slightly more complex UI. The MozJPEG encoder is genuinely better than browser-native JPEG, and it supports WebP, AVIF, and other modern formats. It’s the technically superior tool.

Use QuickShrink when you want the fastest possible workflow: drop image, download compressed version, done. No format decisions, no sliders, no settings panels. The Canvas API approach trades 3-4% compression efficiency for massive speed gains and zero complexity. I use it daily for blog images and documentation screenshots — exactly the use case where “good enough compression, instantly” beats “perfect compression, eventually.”

Use TinyPNG when you’re batch-processing hundreds of images through their API and don’t have privacy constraints. Their WordPress plugin and CLI tools are well-maintained. At $0.009/image after the free 500, it’s cheap automation.

Skip iLoveIMG unless you specifically need their PDF tools. The silent downscaling and middling compression don’t justify using a server-side tool when better client-side options exist.

Skip Compressor.io — Squoosh does everything it does, client-side, with better compression.

The Broader Point: Why Client-Side Tools Win

The web platform in 2026 is absurdly capable. The Canvas API, WebAssembly, the File API, Service Workers — you can build tools that rival desktop apps without a single server-side dependency. And when your tool runs entirely in the user’s browser:

• No hosting costs — static files on a CDN, done
• No privacy liability — you never touch user data
• No scaling problems — every user brings their own compute
• Offline capable — works on planes, in cafes with bad wifi, wherever

This is why I build browser-only tools. Not because client-side compression is always technically best — Squoosh’s MozJPEG proves server-grade encoders can run client-side too via WASM. But because the combination of speed, privacy, and simplicity makes it the right default for 90% of developer workflows.

Try QuickShrink with your own images and see the numbers yourself. And if metadata privacy matters too, run those same photos through PixelStrip — it strips EXIF, GPS, and camera data the same way: entirely in your browser, with nothing uploaded anywhere. For managing code snippets without yet another Electron app, check out TypeFast.

Tools for Your Developer Setup

If you’re optimizing your development workflow, the right hardware makes a difference. A high-resolution monitor helps when comparing compression artifacts side-by-side (I use a 4K display and it’s the first upgrade I’d recommend). For photography workflows, a fast SD card reader eliminates the bottleneck of transferring images from camera to computer. And if you’re processing images in bulk for a client project, a portable SSD keeps your originals safe while you experiment with compression settings — never compress your only copy.

The Pomodoro Technique — work for 25 minutes, break for 5 — has been around since 1987. The science backs it up: time-boxing reduces procrastination and improves focus. But here’s the problem: most people try it for three days and quit. Not because the technique fails, but because a plain countdown timer gives you zero reason to come back tomorrow.

Why Streaks Change Everything

Duolingo built a $12 billion company on one psychological trick: the daily streak. Miss a day and your streak resets to zero. It sounds trivial. It works because loss aversion is 2x stronger than the desire for gain (Kahneman & Tversky, 1979). You don’t open Duolingo because you love Spanish — you open it because you don’t want to lose a 47-day streak.

The same psychology applies to focus timers. A countdown from 25:00 gives you no stakes. A countdown that says “Day 23 of your focus streak” gives you skin in the game.

How FocusForge Applies This

FocusForge adds three layers to the basic Pomodoro timer:

• XP — every completed session earns experience points (25 XP for a Quick session, 75 XP for a Marathon)
• Levels — Rookie → Apprentice → Expert → Master → Legend → Immortal. Each level has its own badge.
• Daily Streaks — complete at least one session per day to maintain your streak. Miss a day, restart from zero.

The actual Pomodoro technique is unchanged. You still focus for 25 minutes (or 45 or 60). But now there’s a reason to do it consistently.

👉 Try FocusForge on Google Play — free with optional $1.99 upgrade to remove ads.

Related Reading

Want to know more about FocusForge’s design and gamification mechanics? Read the full deep-dive: FocusForge: How Gamification Tricked Me Into Actually Using a Pomodoro Timer. FocusForge is part of our suite of 5 free browser tools that replace desktop apps — including NoiseLog, a sound meter app for documenting noise complaints.

EXIF stands for Exchangeable Image File Format. It’s a standard that embeds technical metadata inside every JPEG and TIFF photo. When you share a photo, this invisible data goes with it — including your GPS location.

What EXIF Data Contains

EXIF was created in 1995 for digital cameras. The original intent was helpful: let photographers review their camera settings (aperture, shutter speed, ISO) after the fact. But smartphones added fields the standard’s creators never anticipated:

• GPS coordinates — latitude, longitude, altitude
• Phone model — exact make and model
• Unique device ID — camera serial number that’s the same across all your photos
• Date and time — when the photo was taken and last modified
• Software — which app last edited the image
• Orientation — how the phone was held

Real Risks

In 2012, antivirus pioneer John McAfee’s location in Guatemala was revealed through EXIF data in a photo posted by a journalist. In 2024, researchers found that 30% of photos on major online marketplaces still contained GPS coordinates, exposing sellers’ home addresses.

If you sell items online, post on forums, or share photos via email — your location data is potentially visible to anyone who downloads the image.

How to Check and Remove EXIF Data

The fastest way: open PixelStrip, drop your photo, and click “Strip All Metadata.” It runs in your browser — no upload, no server, no account. You’ll see exactly what data was hiding in your photo before it’s removed.

👉 Check your photos now

Related Reading

• How to Remove GPS Location from Photos Before Sharing Online — step-by-step guide to stripping location data
• PixelStrip: Your Photos Are Broadcasting Your Location — the tool behind the one-click metadata removal
• 5 Free Browser Tools That Replace Desktop Apps — PixelStrip and more privacy tools that run in your browser

You don’t need to install an app for everything. These browser-based tools work instantly — no download, no account, no tracking. They run entirely on your device and work offline once loaded.

1. Image Compression → QuickShrink

Instead of installing Photoshop or GIMP just to resize an image, open QuickShrink. Drop an image, pick quality (80% is ideal), download. Compresses using the same Canvas API that powers web photo editors. Typical result: 4MB photo → 800KB with no visible difference.

2. Photo Privacy → PixelStrip

Before sharing photos on forums or marketplaces, strip the hidden metadata. PixelStrip shows you exactly what’s embedded (GPS, camera model, timestamps) and removes it all with one click. No upload to any server.

3. Code Snippet Manager → TypeFast

If you keep a file of frequently-used code blocks, email templates, or canned responses, TypeFast gives you a searchable list with one-click copy. Stores everything in your browser’s localStorage — no cloud sync needed.

4. Focus Timer → FocusForge

A Pomodoro timer that adds XP and streaks to make deep work addictive. Three modes: 25, 45, or 60 minutes. Level up from Rookie to Immortal. Available on Google Play for Android.

5. Noise Meter → NoiseLog

Turn your phone into a sound level meter that logs incidents and generates reports. Perfect for documenting noise complaints with timestamps and decibel readings. Available on Google Play.

Why Browser-Based?

• No install — works immediately in any browser
• Private — data stays on your device
• Fast — loads in milliseconds, not minutes
• Cross-platform — works on Windows, Mac, Linux, iOS, Android
• Offline — install as PWA for offline use

Deep Dives

Want the full story behind each tool? Read our detailed write-ups: QuickShrink: Why I Built a Browser-Based Image Compressor, PixelStrip: Your Photos Are Broadcasting Your Location, and TypeFast: The Snippet Manager for People Who Refuse to Install Another App.

All tools are open source: github.com/dcluomax/app-factory

Every time you take a photo with your phone, the exact GPS coordinates are embedded in the image file. When you share that photo online — on forums, marketplaces, or messaging apps — anyone who downloads it can see exactly where you were standing. Here’s how to remove it in 3 seconds.

Quick Fix: Strip All Metadata

1. Open PixelStrip
2. Drop your photo on the page
3. See the metadata report (GPS coordinates highlighted in red)
4. Click “Strip All Metadata & Download”

The downloaded photo looks identical but contains zero hidden data. No GPS, no camera model, no timestamps.

What Metadata Is Actually in Your Photos?

EXIF metadata was designed for photographers to track camera settings. But smartphones added fields that reveal far more than you’d expect:

• GPS Latitude/Longitude — accurate to within 3 meters on modern phones
• Device Model — “iPhone 16 Pro” or “Samsung Galaxy S25” — narrows down who took the photo
• Date & Time — the exact second the photo was captured
• Camera Serial Number — a unique identifier that links photos from the same device
• Thumbnail — a smaller version that may contain content you cropped out

Which Platforms Strip Metadata Automatically?

Do strip metadata: Facebook, Instagram, Twitter/X, WhatsApp (when sent as photo, not file)

Don’t strip metadata: Email, Telegram (file mode), Discord, Forums, Craigslist, eBay, Dropbox, Google Drive shared links

If you’re sharing via any channel that doesn’t strip metadata, do it yourself first.

👉 Strip your photos with PixelStrip — no upload, no account, 100% in your browser.

Related Reading

• What Is EXIF Data? (And Why You Should Remove It) — understand what metadata is hiding in your photos
• PixelStrip: One-Click EXIF and GPS Removal — the browser-based tool that strips all metadata instantly
• How to Compress Images Without Losing Quality — after removing metadata, shrink file size too

You need to send a photo by email but it’s 8MB. You need to upload a product image but the CMS has a 2MB limit. You need to speed up your website but your hero image is 4MB. The solution is always the same: compress the image. But most tools upload your photo to a random server first.

Here’s how to compress images without uploading them anywhere, using only your browser.

The 30-Second Method

1. Open QuickShrink
2. Drag your image onto the page (or click to select)
3. Adjust the quality slider — 80% gives great results for most photos
4. Click Download

That’s it. Your image never leaves your device. The compression happens entirely in your browser using the Canvas API — the same technology that powers web-based photo editors.

What Quality Setting Should I Use?

80% — Best for most photos. Reduces file size by 40-60% with no visible difference. This is what most professional websites use.

60% — Good for thumbnails, social media, and email attachments. 70-80% smaller. You might notice slight softening if you zoom in, but it looks perfect at normal viewing size.

40% — Maximum compression. 85-90% smaller. Visible artifacts on close inspection, but fine for previews and low-bandwidth situations.

100% — No compression. Use this only if you need to convert PNG to JPEG without quality loss.

Why Not Use TinyPNG or Squoosh?

TinyPNG uploads your image to their servers. For personal photos or client work, that’s a privacy concern. Also limited to 20 free compressions per month.

Squoosh (by Google) is excellent and also runs client-side. But it’s heavier — loads a WASM codec and has a complex UI. If you just want to shrink a photo fast, it’s overkill.

QuickShrink is a single HTML file, loads in under 200ms, works offline, and does one thing: make your image smaller. No account, no limits, no tracking.

👉 Try QuickShrink — free, forever, private by design.

Related Reading

• QuickShrink: Why I Built a Browser-Based Image Compressor — the story behind the tool and how it works under the hood
• PixelStrip: Strip Hidden Metadata from Photos — after compressing, remove GPS and device data too
• 5 Free Browser Tools That Replace Desktop Apps — QuickShrink, PixelStrip, and more privacy-first tools