DEV Community: JigsawLabs

Where Did 90% of My Photo Go? JPEG Compression, Explained Gently

JigsawLabs — Thu, 15 Oct 2026 10:23:50 +0000

Drag a 4 MB photo into a compressor, and a few seconds later you get a 400 KB file that looks… the same. Nine-tenths of the data is gone and your eye can't find the hole. That should bother you more than it does. Where did 90% of the photo go?

The answer is one of the most elegant engineering stories in everyday software — JPEG, designed in 1992 and still compressing most of the internet's images. It works because it knows three things about you: what your eye measures sharply, what it measures poorly, and what it ignores completely. Compression isn't about shrinking data; it's about knowing which data was never really seen.

Our Compress Images tool runs this machinery in your browser. Let's open it up — three tricks, climbed step by step.

Trick 1 — Your eye is sharp on brightness, blurry on color

Hold a red pen and a blue pen at arm's length, tips touching. You can see the exact pixel-sharp boundary between light and shadow on each pen — but the boundary between the two colors is mushier to you than you think. Human retinas carry ~120 million brightness sensors and only ~6 million color sensors. You live in a world of crisp luminance and approximate color, and you've never noticed.

JPEG's first move exploits this ruthlessly. It converts every pixel from "red, green, blue" into "brightness + two color channels," then stores the color channels at half the resolution in each direction — one color sample per 2×2 block of pixels. That's called chroma subsampling, and it deletes half of all the data before any real compression begins.

Look at the recombined panel in the figure. The color layer was stored at a quarter of the size — and you cannot tell. The first 50% of the "missing" photo was never visible to you in the first place.

Trick 2 — Every 8×8 block is a recipe of waves

Now the clever part. JPEG chops the brightness layer into little 8×8 pixel blocks — 64 numbers each — and asks a strange question about every block: instead of storing your 64 pixel values, what if I stored your recipe?

Here's the idea in one dimension first. Any curve — say, the brightness along one row of pixels — can be built by adding up waves: one broad smooth wave for the overall trend, plus smaller, faster ripples for the fine texture. This is the famous idea of Fourier, from 1822: complicated signals are sums of simple waves.

In two dimensions, the waves become 64 standard patterns — from "completely flat" in the top-left corner, through broad soft gradients, down to a microscopic checkerboard in the bottom-right. This is the Discrete Cosine Transform (DCT), and the 64 patterns are its alphabet:

The DCT rewrites each block as a recipe: "a lot of pattern 1, a pinch of pattern 2, zero of pattern 59…" Crucially, nothing is lost yet — 64 pixel numbers became 64 recipe numbers, and the block can be rebuilt perfectly.

So why bother? Because photographs are overwhelmingly smooth. Sky, skin, walls, blur — across an 8×8 block (that's a speck a couple of millimeters wide on your screen), brightness barely changes. So in block after block, the recipe says: big amounts of the smooth top-left patterns, and amounts of the busy patterns that are nearly zero. The DCT doesn't delete anything — it sorts the information by how much your eye cares, smooth and visible at one end, microscopic and invisible at the other. It sets up the kill.

Trick 3 — The quality slider is a rounding dial

Now the deletion — and the real meaning of that "quality" slider you've dragged a hundred times.

Take each recipe amount and divide it by a step size, then round to the nearest whole number. High quality = small steps: dividing 42 by 4 and rounding gives 11 — most of the information survives. Low quality = big steps: dividing 42 by 24 gives 2, and dividing that near-zero fine-texture amount by 24 gives… 0. And 0 is the magic word, because a long run of zeros costs almost nothing to store.

That's the entire quality dial: how coarsely are the wave amounts rounded. Quality 90 rounds gently and keeps fine texture. Quality 45 rounds harder — in the figure the picture still looks fine, at a third of the bytes. Quality 8 rounds so brutally that only each block's average survives, and suddenly you can see the 8×8 blocks themselves — the famous JPEG blockiness is literally the grid of the algorithm showing through.

After rounding, the surviving numbers are read out in a zigzag (so the zeros bunch together at the end) and squeezed with classic lossless tricks — run-length counting and Huffman coding, the "say it shorter if it's common" family. But the hard decisions are already made. The file is small because the rounding dial decided which waves you'd never miss.

So where did the 90% go?

Half was color detail your retina never had sensors for. Most of the rest was fine-texture wave amounts that were already near zero and got rounded to exactly zero. What's left — the broad shapes, the edges, the brightness your eye actually measures — survives nearly untouched. The photo didn't lose 90% of what you see. It lost 90% of what you were never seeing.

One practical note from our own tool: compression this good is also why re-compressing a JPEG over and over degrades it — each pass re-rounds the recipes, and the rounding errors stack. Compress from the best original you have, once, at the quality you need.

Try the dial yourself and watch the bytes fall as you drag: jigsawlabs.tools/tools/image-shrink — free, no signup, and like every JigsawLabs tool it runs entirely in your browser, so your photos never leave your device.

Originally published on the JigsawLabs Blog. This is the fourth post in a series on the engineering inside JigsawLabs tools: the 55 KB brain that formats documents, how an AI cuts you out of a photo, and how OCR reads photos.

How a Browser Reads a Photo — OCR Explained Step by Step

JigsawLabs — Thu, 15 Oct 2026 10:20:18 +0000

Take a photo of a printed page and ask your computer to type it out. The job sounds like one step — "read it" — but a computer starts from a place so humble it's almost funny: all it has is a grid of millions of brightness numbers. Nothing in that grid says "letter." Nothing says "word." There is no text in a photo of text.

Optical character recognition — OCR — is the staircase from those raw numbers up to the sentence you can copy-paste. It has only three stairs, and each one is honest enough to explain completely. Let's climb them with a real example: a phone photo of meeting notes, slightly shadowed on one side, like every photo ever taken in a hurry.

Step 1 — Every pixel becomes ink or paper

First problem: the photo is a mess of grays. The paper isn't white (it's in shadow on the right), and the ink isn't black (cameras soften everything). Before any reading happens, OCR wants a brutally simple world: every pixel is either ink or paper. Nothing in between.

How do you pick the cutoff? Count the pixels. Make a histogram — a bar chart of "how many pixels have each brightness, from 0 (black) to 255 (white)." A photo of text always shows the same beautiful shape: two hills. A big hill of bright pixels (all that paper) and a smaller hill of dark pixels (the ink). Between them: a valley.

The cutoff should sit in that valley — and a method from 1979 called Otsu's method finds it with pure arithmetic: try every possible threshold from 0 to 255, and for each one, measure how cleanly it splits the pixels into two tight groups. Keep the threshold with the cleanest split. That's the whole algorithm — a for-loop, no AI. On our sample photo it lands on 104:

Every pixel darker than the valley becomes pure black; everything brighter becomes pure white. The shadow vanishes — because the shadow's pixels, dark as they were, still sat on the bright side of the valley. This step is why decent OCR tools shrug off bad lighting that would ruin a naive "is it dark?" rule.

Step 2 — Find the text before reading it

Now the page is black ink on white paper, but the computer still doesn't know where the words are. The fix is geometry, not intelligence.

Black pixels that touch each other get grouped into clumps — each clump is a letter (or a few letters stuck together). Clumps that sit close together on the same baseline become a word. Words sharing a baseline become a line. It's exactly how you'd organize spilled beads: things that are near each other and aligned probably belong together.

The output of this stair is a stack of little image strips, one per line of text, each handed to the reader with a note attached: "this strip contains exactly one line — read it."

Step 3 — Reading is a sequence, not a lookup

Here is where old OCR and modern OCR part ways, and the difference teaches a real lesson about machine learning.

Old OCR tried to cut each word into individual letters and match each letter against stencils — does this blob look like the "B" template? It worked on clean typewriter fonts and fell apart on everything else, because real text refuses to be cut: letters touch, fonts vary, and in cursive scripts the letters flow into each other.

Modern OCR — the engine in our tool is Tesseract, with its neural "LSTM" reader — stops trying to cut. Instead, a small network slides along the strip like a reading head, a few pixels at a time. At every step it shouts probabilities: "81% this is part of a d, 9% maybe cl…" — and crucially, it carries memory of what it has already seen. Having read "Budge…", it strongly expects a t next. (The memory cell it uses is called an LSTM — "long short-term memory" — which is exactly what it sounds like: a little notebook the network keeps as it reads.)

But wait — the head takes twelve little steps across a six-letter word, so its raw output is a stutter: "B B u u _ d d g _ e t t". A wonderfully simple trick called CTC turns the stutter into text: collapse the repeats, drop the silences. "BBuu_ddg_ett" becomes "Budget". The deep consequence: nobody ever has to tell the network where one letter ends and the next begins — it learns its own timing from examples, which is precisely what made letter-cutting unnecessary.

Why Arabic is the real test

Our tool reads English and Arabic — and Arabic is where the sequence approach proves itself. Arabic script is cursive by design: most letters connect, and a letter changes shape depending on whether it sits at the start, middle, or end of a word — the same letter can look four different ways. Stencil-matching has no chance. But a reader with memory, sliding along the line (right to left, this time), handles it the way a human reader does: shape-in-context. That's why the tool ships two trained models, one per language, each a few megabytes of learned weights — downloaded once to your browser, cached, and run locally.

And that sentence is doing a lot of work: locally. Receipts, contracts, IDs, prescriptions — photos of text are the most sensitive images people process online, and the standard OCR site uploads them to a server. Ours doesn't have a server to upload to. The staircase you just climbed — histogram, valley, clumps, boxes, sliding reader — runs inside your tab, and you can watch the network panel stay silent while it works.

Try it on your own messy photo — English, Arabic, or both at once: jigsawlabs.tools/tools/image-to-text — free, no signup, and the photo never leaves your device.

Originally published on the JigsawLabs Blog. This is the third post in a series on the engineering inside JigsawLabs tools: the 55 KB brain that formats documents and how an AI cuts you out of a photo.

How an AI Cuts You Out of a Photo — 24 Million Decisions at a Time

JigsawLabs — Thu, 15 Oct 2026 10:10:44 +0000

Tap "remove background" and something has to happen to every single pixel.

A photo from a modern phone has about 12 million pixels. For each one, the tool must answer a question: are you part of the person, or part of the background? Twelve million questions — and here is the twist that makes this problem genuinely hard: yes and no are not good enough.

Zoom into the edge of someone's hair. Keep zooming, until you can see individual pixels. Now find the exact pixel where "person" stops and "background" begins. You can't — because there isn't one. A single pixel at the wispy edge of a curl is partly hair and partly the wall behind it. Its color is literally a blend: some fraction hair, the remaining fraction wall. The same is true along shoulders, around fingers, through anything slightly out of focus.

So the real question the tool must answer, twelve million times over, is not "person: yes or no?" but "person: how much, from 0% to 100%?" Get those percentages wrong and you get the look everyone recognizes from cheap cutouts: helmet hair, jagged halos, edges that look scissored by a hurried child.

Answering a percentage question millions of times, correctly, in a couple of seconds, on your own device — that is the whole story of a background remover. The rest of this post is just: how?

Step 1 — What the AI actually draws: the alpha matte

Here is the surprise that unlocks everything else: the neural network never cuts anything. It cannot delete pixels, and it never touches your photo.

It draws a second image.

That second image is the same size as your photo, but it's a ghost: pure grayscale, no colors. Each of its pixels holds exactly one number — the answer to the question above for the matching pixel of your photo. White means 100%: "this pixel is fully person." Black means 0%: "fully background." And the grays in between are the whole reason this works: a middle gray at the edge of a curl means "this pixel is about half hair."

This ghost image has a name: the alpha matte. The word matte is older than computers — it comes from cinema, where artists painted mattes on glass to block out parts of the frame, long before green screens. The film industry's problem a century ago was exactly ours: how do you say, for every point of the picture, how much of it belongs to the foreground?

Once you have the matte, "removing the background" stops being intelligent work at all. Your photo supplies the colors; the matte supplies the percentages; gluing them together as an image-with-transparency is one mechanical pass. The person keeps her exact pixels — every strand at 100% — and each half-hair edge pixel becomes half-transparent, which is what lets it sit softly on whatever comes next: pure white for a passport photo, a beach, anything.

So when you tap the button, the intelligence has exactly one job, and it is weirdly artistic: stare at a photograph and paint its ghost — 12 million careful shades of gray. Everything after that is arithmetic.

Step 2 — How the ghost-painter thinks: two artists, one canvas

Meet the painter. The tool on jigsawlabs.tools uses a neural network called MODNet — a design that came out of university research on portrait matting, and the same network we ship to your browser. What makes it worth explaining is that its inner structure mirrors something you already do with your own eyes.

Look at a portrait and squint. Details vanish; blobs remain. Even blurred, you know exactly where the person is — a squint is enough for the shape. Now lean in close to one spot — say the boundary of a shoulder. Up close you can trace the edge precisely — but if I only ever showed you that zoomed patch, you couldn't tell me whether it belongs to a shoulder or a shoe.

Those are two different skills, and they fail in opposite ways. So MODNet is built, literally, as two artists sharing one canvas:

The squinter works on a shrunken copy of your photo. Detail is gone, so it can only judge the big picture — and that's the point. Its half of the job: paint a rough, blurry silhouette. The person is HERE. It is wise about "where" and hopeless about "exactly."

The edge-tracer works close to full resolution, but only cares about a narrow band of the image: the boundary region the squinter pointed at. Along that band it does the delicate work — the strands, the soft blur where a curl meets the wall, the gap between arm and body. It is precise about "exactly" and clueless about "where."

A third stage — call it the editor — merges the two: the squinter's silhouette everywhere, the edge-tracer's fine grays wherever the two overlap, one clean matte out. (In the research paper these are the semantic, detail, and fusion branches; the paper's real contribution was training all three to cooperate in one pass, fast enough for real time.)

Here's the sentence worth remembering from this whole section: the network doesn't succeed because it's huge — it succeeds because the problem was split the way vision actually works. Shape is a low-resolution question. Edges are a local question. Neither needs the other's data, so neither wastes capacity on the other's job.

And how did the artists learn their crafts? The boring, honest answer: practice. The network was trained on many thousands of portrait photos that came with hand-made, pixel-perfect mattes — guess, compare, adjust, millions of times, until its guesses stopped being guesses. There is no rulebook inside that says "hair is thin and wispy"; there are only numbers that drifted, example by example, toward painting good ghosts.

Step 3 — The whole trick is one line of math

I promised math, and here it is — the entire "put me on a beach" feature, the same line our tool runs for every pixel:

new pixel = α · person + (1 − α) · new background

That α (alpha) is the matte's number for this pixel, written as 0-to-1 instead of a percentage. Read the line aloud and it turns out you already knew it: take α parts of the person, fill the rest with the new background.

Watch it work on three pixels:

A pixel in the middle of the face: α = 1. The formula collapses to new = person. Untouched — which is why nobody's cheek ever gets "processed."
A pixel of open sky in the new background: α = 0. It collapses to new = background. Pure beach.
And the pixel from the start of this post — the one that was 62% hair over a wall: α = 0.62. The result is a real mix: 62% of the dark hair color plus 38% of whatever now sits behind — sky blue, passport white. The formula manufactures exactly the in-between color your eye expects at a soft edge. That's the whole secret of hair that doesn't look scissored: the edge isn't preserved, it's recomputed against the new background.

Want to feel it instead of reading it? We built a tiny playground where you drag α and the equation computes live: the alpha compositing playground — it runs the exact line above on colors you pick.

One line, three multiplications and an addition per color channel, twelve million pixels — your phone does it in the blink of a frame. The film industry has a name for this too: alpha compositing, formalized back in 1984 by Porter and Duff, and it is quietly running under every movie green-screen shot, every game HUD, every translucent window on your screen. Our tool didn't invent the glue; it earned the α.

And that's a clean split worth saying out loud: the neural network's ONLY job was those α values. Everything visible after that — remove, replace, passport white — is this one honest line of arithmetic.

Step 4 — The pasted look, and the statistics that fix it

Perfect edges are not enough. You have seen the proof a hundred times: a cutout with flawless hair, dropped onto a sunny beach — and still, instantly, unmistakably pasted. Why?

Because light is a liar you can't un-hear. The original photo was taken under warm indoor lamps; the beach is cool, bright, blue-shifted. Every pixel of the person still carries the fingerprint of the old room, and your eye — superbly trained by a lifetime of real scenes — notices that the person and the place disagree about what the light is.

Here's the beautiful part: fixing this needs no neural network at all. It needs six numbers.

The color "mood" of an image is captured shockingly well by simple statistics: for each color channel, the average (is this image overall warm? dark? blue?) and the spread (are its colors muted or punchy?). Two numbers per channel, three channels — six numbers describe the light's fingerprint.

So to make a person borrow the beach's light, you shift their statistics toward the beach's statistics. For every pixel of the person, per channel:

new = (old − person_avg) × (scene_spread / person_spread) + scene_avg

Subtract the person's average (remove the old room's fingerprint), rescale by the ratio of spreads (adopt the scene's contrast), add the scene's average (put on the new light). This recipe is called Reinhard color transfer, published in 2001 — done in a color space built to match human perception, and twenty-five years later it remains the workhorse because it is instant, predictable, and has no moods of its own.

One ingredient matters in practice: gentleness. Match the statistics 100% and the person starts dissolving into the scenery — identity sacrificed to atmosphere. That's why our tool exposes it as a strength slider and applies the shift partially: borrow the scene's mood, keep your own face. (In the figure, even a one-third strength shift already makes the "pasted" feeling collapse.)

Step back and look at the full pipeline you now understand: a neural network paints the matte (Step 2), one line of arithmetic recomposes every pixel (Step 3), six statistics make the light agree (Step 4). The "magic" button is a matte, a multiply, and a mood.

The part nobody believes: all of it stayed in your tab

Now the twist that this whole series keeps arriving at from different directions.

Everything you just read about — the ghost-painting network, the twelve million compositing equations, the statistics of light — runs inside your browser tab. Not on our servers. We don't have servers that could do it. When you open the tool, the model travels to you — about six megabytes, once, cached like any image — and from that moment the pipeline runs on your own device. Open your browser's network panel and watch while it works: your photo never leaves.

That one architectural choice quietly deletes the business model of an entire tool industry:

Serving another user costs us nothing, so the tool can be free — no signup, no daily limit, no watermark held for ransom.
Your photo was never sent, so privacy is not a promise we make — it's a property of the design. There is nothing to leak, subpoena, or train on.

The usual way and the browser way differ by a single arrow: either your photo travels to the intelligence, or the intelligence travels to your photo. Everything else — the paywalls on one side, the privacy on the other — is downstream of that arrow's direction.

Try the whole pipeline yourself — drop a photo, watch the matte do its work, slide the harmony strength and see Reinhard's six numbers move a person between worlds: jigsawlabs.tools/tools/remove-background — free, no signup, and your photo stays yours.

Originally published on the JigsawLabs Blog. This is the second post in a series on the engineering inside JigsawLabs tools. The first — What If We Gave the Browser a Small Brain? — explains the 55 KB neural network that formats documents.

What If We Gave the Browser a Small Brain?

JigsawLabs — Thu, 15 Oct 2026 10:07:32 +0000

Here is a question that has been quietly haunting me:

What is a browser actually capable of?

We treat it as a window — a pane of glass we look through at software running somewhere else. Every "intelligent" thing we do online follows the same ritual: our words, our photos, our files travel to a distant computer, something happens there, and the result travels back. The browser just displays it.

But the device you are reading this on is a supercomputer by any historical standard, and the browser is the most widely deployed runtime in human history — sitting on billions of machines, capable of running real computation, and mostly used to render other people's servers.

So the question sharpens into something more interesting:

What if we gave the browser a small brain? Not a connection to intelligence somewhere else — an actual resident intelligence, living inside the page the way a stylesheet does. What power could we unleash on the devices we already own?

Hold that question. This post is about the first place it landed for me — and the surprisingly small amount of mathematics it took to answer it.

The first place the question landed: documents

I work with documents constantly, and like most people I don't produce them in one sitting — I produce fragments. Meeting notes on a laptop. Half an outline dictated into a phone. Bullet points pasted from three chats. And every few days comes the moment where the scattered pile has to become a presentable document: a real one, with a cover page, headings, numbered sections, a table that looks like a table.

The gap between "text I have" and "document I can send" is tiny in theory and maddening in practice. So the haunting question turned concrete:

What if a browser tool could look at my scattered notes and understand — even a little — how they should be formatted? What if it lived entirely in the tab: nothing to download, nothing to install, no signup, no upload? How much friction would simply disappear?

Notice what the last part rules out. The tools that promise this today almost all work the same way: upload your text to our server, and our AI will handle it. That sentence deserves more suspicion than it gets. Notes contain client names, unreleased plans, half-formed ideas — a meeting summary is one of the most sensitive documents a person produces all week, and the standard workflow ships it to someone else's computer to get a cover page stapled on.

I wanted the intelligence to come to the document, not the document to the intelligence. The answer turned out to be a neural network with 6,471 parameters that weighs 55 KB — smaller than the favicon on some websites. I think of it as a small brain, and I've come to believe small brains are one of the most underrated ideas in software right now.

The landscape: cathedral AI

Today's defining AI systems are cathedrals: hundreds of billions of parameters, running in datacenters, reached through an API. They are genuinely remarkable, and for open-ended work — writing, reasoning, conversation — nothing smaller comes close.

But the cathedral model quietly became the default architecture for every intelligent feature, including ones that never needed it. Want to detect whether a line of text is a heading? Send the document to the cloud. The result is a strange bargain that we've all stopped noticing: to make text prettier, you surrender the text.

There's a second cost besides privacy: economics. Every cloud call costs the tool's maker money, which is why "free" document tools come with signups, watermarks, daily limits, and pricing pages. The paywall isn't greed, mostly — it's physics. Someone has to pay for the datacenter.

Flip the architecture and both costs vanish at once. If the intelligence runs on the user's own device, the marginal cost of serving one more user is zero — so the tool can actually be free — and the data never moves, so privacy isn't a policy, it's a property of the design.

The question is whether device-sized intelligence is enough for the job. For document structure, it turns out 55 KB is plenty. Here's why.

The problem, precisely

Take this fragment of a messy note:

QUARTERLY REVIEW
prepared by finance team

Revenue: 410K
Costs: 180K

next steps
- hire two engineers
- renegotiate hosting contract

You parsed that instantly, without being told: a title, a byline, two key–value pairs, a heading ("next steps"), a list. Formatting a document is exactly this act of seeing structure — deciding, for every line, what role it plays. Once each line has a role, the rest is mechanical: titles get cover pages, headings get accent colors and numbering, lists get bullets, tables get borders.

So the whole intelligent part of the problem compresses into one question:

Given a line of text, is it a TITLE, a HEADING, BODY text, a LIST item, a KEY–VALUE pair, a TABLE row — or NOISE (page numbers, boilerplate) that should be thrown away?

Seven categories. That's it. This is not open-ended reasoning; it's a classification problem — and classification problems this small have been solvable since long before the cathedral era.

How the small brain works

You could try rules: "if a line is short and ends with a colon, it's a heading." Rules get you surprisingly far — and then betray you. Is Revenue 2024: a heading, or a key–value pair missing its value? Is a short capitalized line a title, or an angry sentence? Every new rule you add to fix one case breaks another. Rule systems don't degrade gracefully; they argue with themselves.

The alternative is to let the boundaries be learned from examples. Here's the entire recipe — this is genuinely all of it:

1. Measure each line. The model never sees words. Each line is reduced to 31 numbers — honest, human-readable measurements: How long is it? What fraction is digits? Does it start with a bullet character? End with a colon? Is it ALL CAPS? Does it look like key: value? Is there a blank line above it? Whereabouts in the document does it sit?

2. Add context. A line alone can be ambiguous; a line between two other lines rarely is. (Revenue: 410K directly above Costs: 180K is clearly part of a key–value block.) So the model looks at each line together with its neighbors: 31 numbers × 3 lines = 93 inputs.

3. One layer of neurons. The 93 inputs feed 64 tiny decision units. Each one computes a weighted sum of everything it sees and stays silent unless the evidence crosses its threshold — a "neuron" is nothing more mysterious than that. Their 64 outputs are combined into 7 scores, one per category, and the scores become probabilities.

That's the whole brain: 6,471 learned numbers. For comparison, the models behind chatbots have hundreds of billions. This one is roughly fifty million times smaller — because the question it answers is fifty million times narrower.

On held-out test documents it labels 99.8% of lines correctly. A tuned rule-based system reaches about 99.1% on the same test — so the honest claim is not that the network is magic, but that it cleanly wins the ambiguous cases where rules argue with themselves, and it never gets worse as it learns new document styles. (When it is unsure, the tool falls back to conservative formatting — a wrongly-bolded line is annoying; a deleted one is unforgivable.)

And because it's 55 KB of arithmetic, it classifies an entire document in about a millisecond, on a phone, offline.

What this makes possible

This architecture became DocForge, a free tool I built: paste text (or Markdown), pick a template, and it assembles a finished Word document — cover page, styled headings, tables, even rendered diagrams — entirely inside your browser tab. Open DevTools while it works and watch the network panel: nothing is transmitted. There's no server to upload to; the "AI feature" is those 55 KB, cached with the page.

The consequences are exactly the two from earlier, now running in reverse:

It's free without a catch, because a million users cost the same to serve as one: nothing. No accounts, no watermarks, no "3 documents per day."
It's private by construction, not by promise. No privacy policy can be violated for data that was never sent.

Back to the haunting question

So — what is a browser capable of? More than we let it do.

We treat "AI feature" as a synonym for "cloud feature", but a huge share of everyday intelligence — is this a heading or a list? is this photo's subject in focus? which language is this receipt in? — consists of narrow questions, and narrow questions have small answers. Small enough to ship with the page, like a stylesheet.

Imagine that as the default: spellcheck-sized brains embedded in every text box, image tool, and file converter on the web — each one specialized, inspectable, offline, and free, because it costs nothing to run. The cathedrals will keep doing what only cathedrals can do. But most of what we actually need from software intelligence, most days, would fit in a parish chapel — and the parish chapel fits in a browser tab you already have open.

The document-tools industry built paywalls on top of a cost structure that small brains simply delete. I don't think that industry has noticed yet. The power was on our devices all along; we just kept looking through the window instead of using the room.

Originally published on the JigsawLabs Blog. DocForge is free, has no signup, and runs entirely in your browser: jigsawlabs.tools/tools/docforge. I build free, private, browser-based tools at jigsawlabs.tools — if this post's ideas appeal to you, that's where they live.