DEV Community: Joseph Orduna

How I generate llms-full.txt for 1,500 tools at deploy time (so it never goes stale)

Joseph Orduna — Thu, 12 Nov 2026 15:32:07 +0000

A few weeks ago I wrote about serving llms.txt so AI assistants can cite my site accurately (here's that post). The pushback I got was interesting: "nice idea, but who maintains that?" A hand-written list of URLs rots in a month. When a site has hundreds or thousands of pages, any file you maintain by hand will go stale, and a stale llms.txt is worse than none, because it teaches models to cite URLs that 404.

So I stopped maintaining it. A script generates it at deploy time now.

The rule: the registry is the source of truth

My site has a central registry of tools, and every tool page is rendered from it. That is the key precondition: if your CMS or build system knows about every page, an exhaustive plain-text index is a build artifact, not a document.

The generator (scripts/gen-llms-full.js) walks the registry at npm run build and emits llms-full.txt alongside the static output. Deploy regenerates it. Rename a tool, add a category, split a page: the file updates in the same commit. It cannot drift because nobody edits it.

What goes in

The full file for my site is about 120KB of plain text: every tool with its URL, grouped into the 32 categories the site actually uses, with a one-line description per tool. Not marketing copy, just the "what does this page do" line a model needs before deciding to cite it.

A snippet of the shape:

## PDF tools
- Merge PDF files: https://practicalwebtools.com/edit/merge-pdf
- Split PDF by page ranges: https://practicalwebtools.com/edit/split-pdf
- Edit PDF text in the browser: https://practicalwebtools.com/edit/edit-pdf-text

Three decisions worth copying:

Flat list per category, not nested prose. Models extract link+description pairs from - description: URL lines with near-zero error. Nested paragraphs bury the URLs.
Absolute URLs. Relative paths in a plain-text file get mangled when models splice citations into answers. Absolute URLs survive.
One line per tool, no shame about duplication. If a tool belongs in two categories, list it twice with the two descriptions a searcher would use. This is an index, not a database. Redundancy that helps retrieval is free.

llms.txt vs llms-full.txt

The llms.txt convention defines two files: a curated overview (llms.txt) and the exhaustive dump (llms-full.txt). Treat them differently:

llms.txt is your front door. Curated, honest counts, the 20-40 URLs that answer most questions. I rewrote mine after catching it claiming "500+ tools" with two dead links, a claim a model would happily repeat.
llms-full.txt is the site map for machines. Every URL, no curation, generated. Mine lists all ~500 tools, the 460+ unit-conversion pairs, and the 12 Creative Studio apps.

Generate the big one. Curate the small one. Never hand-maintain either.

The payoff is citations, not traffic

Six weeks in, the measurable effect is that AI assistants recommend specific tool URLs instead of the homepage. The deep links models cite match real pages because they read them from the index. That is the whole game: every tool page on my site carries its own summary and FAQ structured data, and the llms index makes those pages findable to models in the first place.

If your build system can enumerate your pages, you can ship this in an afternoon. The script is 40 lines. The hard part is the registry, and if you're rendering pages from data anyway, you already have it. Browse the results yourself at practicalwebtools.com, or read the raw llms-full.txt.

The iframe Auto-Resize Handshake: Engineering Embeddable Widgets That Don't Fight Their Host

Joseph Orduna — Tue, 10 Nov 2026 19:02:32 +0000

If you have ever embedded a third-party widget in an iframe, you know the two failure modes: an inner scrollbar that swallows half the widget, or a 2000-pixel-tall frame with 400 pixels of content. The usual fixes are hacky (hardcoded heights, scrolling=no and prayer). This post is the full engineering notes for the embed surface I run at Practical Web Tools — every calculator on the site (400+, across finance, math, health and science) is embeddable as an auto-sizing iframe, and the whole sizing layer is ~60 lines of framework-free ES5.

The handshake

The framed page measures itself; the host page applies the height. Three pieces:

Inside the frame — measure on load, on every DOM change, and on a few early intervals (cache-cold renders change height late):

var send = function (force) {
  var h = Math.ceil(Math.max(
    document.documentElement.offsetHeight,
    document.body.offsetHeight || 0));
  if (!h || (h === last)) return;
  last = h;
  parent.postMessage({ type: 'pwt-embed:resize', height: h }, '*');
};
new ResizeObserver(function () { send(); }).observe(document.body);
// plus: DOMContentLoaded, load, and 500ms x 40 early ticks

On the host — one listener, matched to the right frame (never document.querySelectorAll('iframe')[0]):

window.addEventListener('message', function (e) {
  if (e.origin !== 'https://practicalwebtools.com') return;
  if (e.data.type !== 'pwt-embed:resize') return;
  var h = Math.min(Math.max(Math.round(e.data.height), 160), 20000);
  // find the iframe whose contentWindow === e.source, then:
  iframe.style.height = h + 'px';
});

The late-script case — if the host's resizer script loads after the frame already reported (async scripts, bottom-of-page pastes), the frame's message is gone. Fix: the host pings back {type:'pwt-embed:ping'} on load and on DOMContentLoaded, and the frame force-sends on ping. No timing assumptions in either direction.

The feedback loop that ate my afternoon

Apply the reported height → the framed page reflows → it reports a new height → apply → reflow. This happens whenever the framed document has any viewport-sized element (a min-height:100vh hero is the classic). The loop's signature: the same height delta each round. So the frame-side code tracks the delta; if |new - last| repeats five times, height reporting stops. The widget might be slightly wrong-sized at that point, but it stops growing forever, which is the difference between "a bit short" and "the page is 40,000 pixels long."

Third-party frames deny your storage

Browsers throw on localStorage access inside cross-origin iframes (Safari is the strictest). A calculator that persists its inputs — the retirement calculator keeps your balances, the GPA calculator keeps your courses — crashes on load inside a frame unless you shim it before any tool code runs:

try { localStorage.setItem('__probe', '1'); localStorage.removeItem('__probe'); }
catch (e) {
  var mem = {};
  window.localStorage = shim(mem);   // getItem/setItem/removeItem/key/length
}

Probe, don't feature-detect once and cache: the probe itself is the detection.

Clicks, links, and not hijacking the host

Inside a frame, a plain link either traps the user in the widget or navigates the host page out from under them. Neither is acceptable. The embed bootstrap intercepts left-clicks on same-site links and rewrites them to window.open(href, '_blank', 'noopener'). Off-site links keep their authored target. The host page never navigates because of something inside the widget.

Ads and embeds don't mix

The site is ad-supported; embeds load zero ads, zero analytics trackers, zero site chrome. This is not altruism — a widget that renders ads onto someone else's article gets ripped out, and rightly so. The framed document drops to a bare tool with a two-line credit bar ("Free calculator by Practical Web Tools" + "Open full calculator"). That credit link is the entire business model, and it ships inside the snippet, in the host page's HTML, as a plain anchor — not injected by script after the fact.

Themes, honestly

"Follow the visitor's OS" paints dark widgets into light articles — the host picked their page's look, not the visitor's OS. Widgets default light and accept an explicit &theme=dark. Boring, correct.

Try it

Every calculator page (say the moon phase tool or the body-fat calculator) shows its own copy-paste snippet with a live preview at the bottom of the page; the flagship hub with the nine one-line script widgets (no iframe at all) is practicalwebtools.com/embed. The MIT-licensed scripts are on GitHub if you'd rather self-host the whole thing.

If you hit a sizing edge case I didn't — especially CSS-driven oscillation — I'd genuinely like to hear about it in the comments.

Tags: javascript, webdev, iframe, widgets

Every Calculator on My Site Is Now a Free Embeddable Widget — No API Key, No Server, No Limits

Joseph Orduna — Tue, 10 Nov 2026 16:42:20 +0000

The widget tax

Google "mortgage calculator widget" and you land on pricing pages: $9–$49/month, API keys, monthly view caps, and watermarks you pay extra to remove. If you run a real-estate blog and want one interactive payment calculator in a post, that's a weird amount of infrastructure for arithmetic.

I run Practical Web Tools, a site with ~500 calculators (finance, math, health, science, everyday) that all run 100% client-side. So I opened the whole catalog up as free embeds. This post is how the embed surface works and what it cost to make it not awful.

Two ways to embed

1. One-line script widgets. Nine flagship widgets — mortgage, loan/amortization, compound interest, BMI, calorie/TDEE, pregnancy due-date, percentage, countdown timer, word counter — each install as two lines:

<div id="pwt-mortgage-widget"></div>
<script src="https://practicalwebtools.com/embed/mortgage-widget.js" defer></script>

These are self-contained static scripts (a shared ~4KB engine renders them). Crucially, there is no iframe pointing at my servers: once the script is on your page, it runs entirely in your visitor's browser. If my site goes down, your embedded widget keeps working. Nothing phones home, because there is no home to phone.

2. Any calculator as an auto-sizing iframe. Every one of the ~500 calculators doubles as a widget at <calculator URL>?embed=1. Each calculator page shows its own copy-paste code; it looks like this:

<iframe src="https://practicalwebtools.com/finance/mortgage-calculator?embed=1"
        title="Mortgage Calculator" loading="lazy"
        style="display:block;width:100%;max-width:880px;height:720px;border:0"
        data-pwt-embed></iframe>
<script src="https://practicalwebtools.com/embed/frame.js" async></script>
<p style="margin:6px 0 0;font:13px/1.5 system-ui,sans-serif">
  Mortgage Calculator by <a href="https://practicalwebtools.com/finance/mortgage-calculator">Practical Web Tools</a>
</p>

The embed URL renders the calculator with all site chrome stripped: no navigation, no ads, no cookie banner — just the tool. A theme=dark parameter pins a dark build when your site has a dark article layout.

How the auto-resize handshake works

The classic iframe-embed wart is the fixed height: too short and you get an inner scrollbar, too tall and there's a blank canyon under the widget. The fix is a tiny postMessage handshake.

Inside the frame, the calculator measures itself on load and on every DOM resize, then posts its height up:

// inside the framed calculator
var send = function () {
  var h = Math.ceil(Math.max(
    document.documentElement.offsetHeight,
    document.body.offsetHeight
  ));
  parent.postMessage({ type: 'pwt-embed:resize', height: h }, '*');
};
new ResizeObserver(send).observe(document.body);

On the host page, a framework-free, ES5-safe script (frame.js, ~1KB) listens for those messages and sizes the matching iframe:

window.addEventListener('message', function (e) {
  if (e.origin !== 'https://practicalwebtools.com') return;
  if (e.data.type !== 'pwt-embed:resize') return;
  // find the iframe whose contentWindow sent this, then:
  iframe.style.height = Math.min(Math.max(e.data.height, 160), 20000) + 'px';
});

If the host's script loads after the frame already reported (script order at the bottom of the page), the host pings back with {type:'pwt-embed:ping'} and the frame re-sends. Net effect: paste the snippet, get a widget that fits, zero configuration.

Things that bit me along the way

Third-party frames deny storage. Browsers often throw on localStorage access inside cross-origin iframes. Several calculators persist their inputs, so the embed bootstrap probes storage and shims in an in-memory fallback (getItem/setItem/removeItem/key/length) before any tool code runs. Without it, half the catalog would crash on frame load in Safari.
Height feedback loops. If the framed page has any viewport-sized element, applying the reported height changes the layout, which reports a new height, forever. The bootstrap detects same-step growth and stops reporting after five iterations rather than stretching the iframe into a scroll bomb.
Ads and embeds don't mix. The site is ad-supported; embeds load zero ads and zero tracking scripts. A widget that renders ads on somebody else's article is a parasite, and site owners can tell.
Theme defaults matter. "Follow the visitor's OS" sounds nice until a dark widget paints itself into a light article. Default is light, with an explicit opt-in for dark.

Who these are for

Real estate / lending blogs — mortgage calculator, loan & amortization with a yearly schedule
Fitness and nutrition sites — BMI and calorie/TDEE (Mifflin-St Jeor)
Deal blogs and retail — percentage calculator (percent-off, % change, is-what-%)
Parenting and pregnancy sites — due-date with trimester breakdown
Personal finance writers — compound interest with contribution schedule
Writing/SEO blogs — live word & character counter

Every calculator's "Embed this calculator" section has a theme picker and a live preview of exactly what your visitors will see, and the snippets work anywhere that accepts custom HTML: WordPress, Squarespace, Wix, Webflow, Ghost, GitHub Pages, documentation sites.

The catch

There is exactly one: a small Calculator by Practical Web Tools link with each widget. No API key, no signup, no view quota, no "upgrade for dark mode," no email wall. If that trade works for you, the full widget catalog is here:

→ Free Embeddable Calculator Widgets — the full catalog

And you can browse all ~500 calculators (every one embeddable from its own page) at practicalwebtools.com/calculators.

If you embed one, drop a comment with where — I keep a list and I'm taking requests for which calculator gets a dedicated one-line script next.

Tags: webdev, javascript, widgets, productivity

Does Re-Saving a JPG Actually Destroy Quality? I Measured 7 Generations of Pixel Loss

Joseph Orduna — Fri, 06 Nov 2026 03:55:56 +0000

Originally published on Practical Web Tools.

Does re-saving a JPG destroy your photo? The honest answer surprised me: I took one test image, re-saved it seven times in a row, and measured the pixel-level damage after every generation. One chain barely changed at all. Another accumulated 7.6 times the error of a single save: with almost no warning in the file size.

The difference between those two outcomes isn't luck. It's three specific behaviors: whether the quality setting stays the same, whether the codec stays the same, and whether each re-save secretly drops the quality a little lower. Once you see the numbers, you'll never guess about image degradation again.

Key takeaway: re-saving at the same quality with the same codec is nearly harmless. Switching codecs or letting quality slide is what actually eats your photos.

How I Ran the Test

Everything below comes from a real experiment, not vendor documentation. Here's the setup so you can judge the results yourself:

Test image: a 1,200 x 800 photographic-style scene: smooth gradients (sky-like), sensor-style noise, and hard dark rectangles mimicking signage and text edges. High-frequency detail plus smooth areas is exactly the mix that stresses image codecs.
Codecs: JPEG and WebP, both at quality 80 for the fixed-quality chains, then a descending ladder from quality 90 down to 30.
Measurement: RMSE (root-mean-square error) between each generation and the pristine original, on the 0-255 pixel scale, plus file size at every step.

A rough guide to reading RMSE numbers: around 3 is barely visible, around 8-10 is visible softness and artifacts when you zoom, and above 20 is objectively mushy. The exact thresholds depend on the image, but the trend is what matters.

I ran three fixed-quality chains first: JPEG only, WebP only, and alternating between the two: then the descending ladders that mimic what social platforms actually do to your uploads.

Myth #1: "Every Re-Save Destroys Your Photo"

This is the one everybody repeats, and it's mostly false. Here's what happened when I re-saved the same image seven consecutive times at quality 80, without changing anything else:

JPEG -> JPEG, seven saves: error went from 3.86 after the first save to 3.87 after the seventh. That's a 0.3% increase: effectively zero.
WebP -> WebP, seven saves: error went from 3.86 to 4.10. Again, nearly flat.
File sizes in both chains stabilized after the second generation and then stopped moving.

The first save is the expensive one. Every same-quality re-save after that is almost free.

Why? Modern encoders are deterministic. When a JPEG at quality 80 is re-encoded at quality 80, the quantization tables match, so the coefficients that survived the first pass mostly survive the second. The damage was already done in generation one; re-applying the same math barely compounds.

So if you've been keeping a "do not touch" JPEG out of fear that opening and re-saving it will grind it into dust: you can relax, as long as your editor doesn't quietly re-compress at a lower quality behind your back. That caveat is where the real damage lives, and it's next.

Culprit #1: Switching Codecs Back and Forth

Now watch what happens when the quality setting stays identical but the codec alternates every save: JPG to WebP to JPG to WebP, seven times at quality 80:

Generation 1 (WebP): error 3.86
Generation 2 (back to JPG): 4.74: a 23% jump from one codec switch
Generation 4: 4.93
Generation 7: 5.02: and still climbing slowly

Each hop between formats re-quantizes the image in a different mathematical basis. JPEG throws away information in 8x8 DCT blocks; WebP does predictive coding plus its own transform. They don't throw away the same information, so every switch carves out a fresh, slightly different slice of detail.

The file sizes told on the chain too: they oscillated between roughly 64 KB and 120 KB depending on which codec had just touched the file, because each format compresses the other's leftovers with different efficiency.

Practical rule: converting formats is a one-way street. Every JPG<->WebP<->PNG round trip adds loss, even at identical quality settings.

This is the trap behind "I just converted it to WebP for my website, then back to JPG for an email, then to WebP again." Three conversions, three fresh rounds of loss. If you need a JPG from an original, go back to the original each time: a proper JPG to WebP converter exists so you can produce the web copy from the master, not from the previous conversion. Same logic in reverse for WebP back to JPG when a form or app demands JPEG.

Culprit #2: The Descending Quality Ladder

Here's the killer, and it's almost never the user's choice: it's what messaging apps and social platforms do silently. Each upload gets re-compressed, often a bit more aggressively than the last. I simulated that with a quality ladder from 90 down to 30, one step per save:

JPEG ladder: error climbed 2.96 -> 4.99 -> 7.35 -> 10.01 -> 12.88 -> 16.54 -> 22.42. By the final step, the image had 7.6x the damage of a single careful save. That's visibly mushy territory.
WebP ladder, same descent: 2.18 -> 4.38 -> 5.32 -> 5.91 -> 6.60 -> 7.36 -> 8.69. Serious, but roughly a third of JPEG's damage.
Alternating ladder (JPG/WebP with quality dropping): ended around 7.0: the WebP hops cushioned the JPEG hits.

One app "optimizing" your upload costs more than five disciplined re-saves at home.

The image-degradation mechanism is simple: once quality 70 has smeared the fine detail away, quality 60 can't preserve what no longer exists: and it smears the remaining structure further. Loss compounds because information never comes back.

The Trap: File Size Stays Flat While Quality Falls

The most useful discovery for everyday sanity checks: in the JPEG ladder, file size collapsed from 226 KB to about 154 KB by the third step: and then plateaued. Steps 3 through 7 all sat near 153-155 KB while error nearly tripled.

So "the file is still 150 KB, it must be fine" is exactly wrong. Later destructive saves can't add bytes back; they spend their bits re-encoding damage. Size tells you how much data survived, not how faithful it is to the original scene.

If you're comparing two versions of an image you downloaded and re-uploaded a few times, don't trust the byte count. Open both at 100% zoom next to the original (or the oldest copy you have) and look at edges: text, hair, brickwork. Edges are where generational loss shows first.

WebP's Unexpected Silver Lining

Two findings favored WebP beyond its famous file-size advantage:

At matched quality numbers, the WebP-only chain stabilized at 95 KB versus JPEG's 123 KB: 23% smaller at essentially equal measured error.
On the descending ladder, WebP degraded far more gracefully (final error 8.69 vs 22.42), because its compression at low quality settings stays closer to the image structure.

That second point matters for anything that passes through other people's pipelines: blog images, marketplace listings, chat apps. Starting from WebP doesn't make re-compression impossible, but it leaves more headroom before things fall apart.

This is also why converting old JPG archives to WebP makes sense once, from the original, and not repeatedly. A single thoughtful conversion captures the size win; repeated cycles capture the loss.

Five Rules That Fall Out of the Data

Everything above compresses (pun intended) into five habits:

Keep a pristine master. The original camera file, or a lossless PNG copy, never gets overwritten. All conversions branch from it. Saving your master as PNG is trivial with a JPG to PNG converter: PNG is lossless, so it freezes the current quality forever.
Convert from the master, never from the previous conversion. This single habit eliminates the compounding chain entirely.
When you must re-save, keep quality constant or higher. Same codec plus same quality is nearly free, per the flat RMSE lines above.
Treat every upload to a platform as a lossy event. Send the highest-quality version the platform accepts; it has the most headroom to survive their ladder.
Watch edges, not file size. Zoom to 100% on text or hair. Byte counts plateau while quality keeps falling.

If you maintain a website, the same rules apply to your image pipeline: compress once at publish time, not at every edit. For batches, running files through a proper compression tool once: instead of letting your CMS re-compress on every save: keeps generations at one.

What This Means for Your Photo Library

Think in terms of a family tree. The master is the trunk; every purpose-built copy (web-optimized WebP, emailed JPG, printed PNG) is a branch cut fresh from the trunk. Branches never grow from other branches.

People who lose photos to generational loss almost always broke that rule by accident: downloaded from WhatsApp, edited, re-saved, uploaded, downloaded again. Five years later the picture looks like a VHS tape: and no single step was obviously to blame.

The math says you'd need dozens of disciplined same-quality re-saves to equal the damage of one careless month on social platforms. Protect the trunk, be careless with branches, and your images will outlive every format war.

The PNG Island Experiment: When Lossless Silently Isn't

A reader scenario worth testing directly: you keep a PNG working copy of a photo that originally arrived as a JPG. Every PNG re-save is lossless, so you're safe forever, right? Mostly: but with one expensive catch I measured.

Converting the damaged JPG (generation 3 of the mixed chain) to PNG froze the damage at exactly that level: every later PNG re-save was pixel-identical, confirmed by RMSE staying flat at 4.77 across five further saves. Lossless holds. But the PNG could not give back what the JPG had already thrown away: and it cost 1,078 KB, eleven times the 95 KB WebP copy, to store a permanently mid-generation image.

That leads to a rule almost nobody follows: convert to PNG only at milestones: final edit, signed-off version, archive point: not as a daily working format for photos. The right order of operations is:

Keep the true original untouched (camera file or first-generation PNG).
Edit and derive freely, converting straight from the original each time.
Freeze a lossless copy when a version is final and must never degrade again.

The failure mode to avoid: importing a WhatsApp JPG into your editor, saving as PNG for safety, editing for weeks, then wondering why the final export looks softer than the photo you remember taking. The damage was imported with the file; PNG just made it permanent and 11x heavier.

Spotting Ladder Damage in the Wild (a 60-Second Audit)

You can run this audit on any suspicious image you've downloaded, without any tools:

Zoom to 100% on text and edges. Ladder damage shows as smeared letterforms and halos around high-contrast boundaries: the JPEG 8x8 grid becomes visible as faint blocking when quality dropped below ~50.
Look at flat areas like sky or walls. Early ladder steps keep them clean; late steps show banding and blotchy color drift, because fine noise was destroyed and the encoder started quantizing structure.
Check the pixel dimensions against the source. Platforms downscale aggressively alongside re-compression; a photo you shot at 4032 px coming back at 1080 px has been through at least one destructive pass regardless of what the app claims.
Compare file size to siblings. Among photos from the same shoot, the one that's dramatically smaller at identical dimensions has been recompressed hardest.

If the audit fails: smeared text plus banding: the copy is a late-generation derivative. Don't restore from it; go back up the chain to the oldest copy you can find. And when you must produce new derivatives of a photo whose original is lost, convert once to a lossless PNG snapshot before any further edits, so the bleeding stops there.

For everything you want to test on your own files, the same conversions I used are free and run entirely in your browser: JPG to PNG for lossless freezing, JPG to WebP for web copies, and PNG to JPG when a form demands JPEG.

FAQ

Does re-saving a JPG at the same quality setting lose quality?
Almost none. In my test, seven consecutive JPEG saves at quality 80 moved measured error from 3.86 to 3.87: a 0.3% change. The first save does the damage; same-quality re-saves barely compound it.

Is converting JPG to WebP lossy?
Yes, one round of loss at conversion time: WebP lossy mode re-encodes the pixels. But at matched quality settings WebP was both smaller (95 KB vs 123 KB in my chain) and gentler under repeated re-compression. Convert once from the original, not in cycles.

How many times can an image be re-saved before quality loss is visible?
At constant quality with one codec: dozens of times with little visible change. With codec switching each time: visible softness can appear within a handful of conversions. With quality dropping each save (the platform ladder): visible damage by the third or fourth step in my test.

Why did my file size stay the same while the image got worse?
Because later lossy saves re-encode existing damage rather than adding new information. My JPEG ladder sat at ~154 KB for five consecutive steps while measured error nearly tripled. File size measures surviving data, not fidelity.

What's the best format for keeping a master copy?
A lossless format: the original camera file (RAW or highest-quality JPG) or a PNG copy. PNG re-saves are pixel-perfect forever, so your master never degrades no matter how many times you open or copy it.

Updated November 3, 2026: The Screenshot Addendum: Flat Graphics Decay Differently

Every test above used photographs. But a reader scenario kept nagging at me: documentation screenshots, diagrams, and exported charts get the same edit-save-edit treatment in JPG, and nobody had measured that class of image. So I ran the chain again on a flat UI screenshot (1600x900: solid fills, a nav bar, text lines rendered as bars): and the results flip two assumptions from the photo tests.

The size plateau is identical, the decay isn't

Five re-saves at a fixed JPEG quality 85, measured against the pristine original each time:

File size: 56 KB -> 57 -> 57 -> 57 -> 57 KB. Dead flat, exactly like the photo ladder.
Pixel drift (RMS): 2.06 at the first encode, then 2.47 -> 2.68 -> 2.87 -> 3.01 across the five re-saves. Same plateau-then-creep shape as photographs, landing in the "barely visible" band overall.
The detail that matters: by generation five, the maximum channel error hit 76 on the 0-255 scale: concentrated exactly where you'd predict: text edges and button borders. Averages hide what screenshots are for. Nobody zooms into sky gradient; everybody zooms into the menu they're trying to read.

The practical takeaway: for flat graphics, judge re-save damage by the edges, not the average. A screenshot can sit at an innocent-looking RMS of 3 while its worst text edges are already ghosting at 30% intensity error.

Why screenshots are the worst-case JPG in the first place

The pristine screenshot weighs 6.6 KB as a PNG and 56 KB as a quality-85 JPG: the lossy format is 8.5x bigger for visibly worse text rendering. So the real fix is upstream: flat graphics should never enter a JPEG chain at all. I've written up the full four-image-type experiment (screenshots, photos, logos, photo-plus-text overlays, including the JPG->PNG round-trip size trap) in a companion piece: PNG vs JPG: I Tested Four Image Types.

The two-step recovery drill

If you're maintaining documentation screenshots that have already been through a JPG chain:

Stop re-saving the damaged file. Each export from the previous export adds another ~0.15 RMS and compounds the edge ghosting: the plateau is forgiving, but it isn't free.
Re-capture from the source when possible. A fresh screenshot (PNG) beats any attempted cleanup of a five-generation JPG, and it will be roughly 8x smaller. For legacy PNG assets that need to travel as JPG, convert the master, not the worn copy: the browser-based JPG converter never touches your original file.
Compress last, from the master. When a doc pipeline demands small files, resize first, then compress in one pass with a client-side image compressor: never through iterative saves.

Originally published on Practical Web Tools. Explore all client-side browser utilities at practicalwebtools.com.

Which Local LLM Fits Your RAM? Best Ollama Models for 4GB, 8GB, 16GB, and 32GB in 2026

Joseph Orduna — Fri, 06 Nov 2026 03:55:51 +0000

Originally published on Practical Web Tools.

The most common local-AI question in 2026 is still the simplest one: "I have X GB of RAM, what should I run?" The answer changed a lot in the last year, because newer model generations got dramatically better at small sizes. A 4B model from the current crop beats 7B models from two years ago, which means old "best models" lists are actively misleading.

Here's the current pick per RAM tier, based on actually running these on real hardware, with honest speed expectations for CPU versus GPU. (Choosing between Ollama and llama.cpp as the runtime is a separate question: we compared the two here; this guide assumes either.)

The one rule that decides everything

Model weights at Q4 quantization (the sweet spot for quality per memory) need roughly 0.6-0.7 GB per billion parameters, plus 1-3 GB of overhead for context and the KV cache. Quick mental math for a machine with 16 GB RAM:

Leave 4+ GB for the OS and browser -> ~12 GB usable
That's a 14B model at Q4 comfortably, or a 24B at Q4 if you close everything else and keep context short

If you have a GPU, the constraint is VRAM instead. GPU VRAM is worth roughly 3-5x CPU RAM for usefulness, because offloaded layers generate several times faster.

4 GB RAM: small, fast, surprisingly capable

The era of "4 GB can't run LLMs" is over. Current small models handle summarization, rewriting, and simple Q&A genuinely well.

Model	Size on disk	Context	CPU speed feel
Qwen3 1.7B (Q4)	~1.1 GB	32k	Snappy, instant-feeling replies
Llama 3.2 3B (Q4)	~2.0 GB	128k	Usable, a paragraph in a few seconds
Phi-4-mini (Q4)	~2.6 GB	128k	Slightly slower, strong reasoning for its size
Gemma 3 4B (Q4)	~2.6 GB	128k	Comfortable if it's the only big app open

Pick: Qwen3 1.7B for speed, Gemma 3 4B if you can spare the RAM. Avoid anything 7B+; it'll thrash.

8 GB RAM: the sweet spot for capable small models

8 GB machines (base Mac mini territory, older laptops) are the first tier where local AI feels like a real assistant rather than a toy.

Model	Size on disk	Context	Notes
Llama 3.1 8B / Llama 3.8B-class (Q4)	~4.7 GB	128k	The default pick; balanced and reliable
Qwen3 8B (Q4)	~5.0 GB	32k+	Stronger coding and math, similar speed
Gemma 3 12B (Q4)	~7.3 GB	128k	Fits, but close everything else; strong multimodal option
DeepSeek-R1 distill 7B/8B (Q4)	~4.5-5 GB	64k	Visible chain-of-thought reasoning; fun to watch think

Pick: Qwen3 8B or Llama 3.1 8B. Go Gemma 3 12B only if 6+ GB is genuinely free. At Q4 with a browser open, 12B on 8 GB is flirting with swap.

16 GB RAM: where local AI gets serious

This is the tier most mid-range laptops and desktops sit at in 2026, and it lets you run 14B-class models that rival cloud models from a couple of years ago.

Model	Size on disk	Context	Notes
Qwen3 14B (Q4)	~9 GB	32k+	The best all-rounder at this tier
Phi-4 14B (Q4)	~9 GB	16k	Excellent reasoning, shorter context
Gemma 3 27B (Q4)	~16 GB	128k	Only fits at Q3 or with very short context, so usually skip on 16 GB
DeepSeek-R1 distill 14B (Q4)	~9 GB	64k	Reasoning workloads, math, logic puzzles

Pick: Qwen3 14B at Q4 as the daily driver. On CPU expect roughly 6-10 tokens/sec: reading speed, fine for chat. With a GPU holding most layers, 25-40 tokens/sec.

32 GB RAM: flagship territory

32 GB comfortably runs the models people actually mean when they say "local AI is as good as the cloud now."

Model	Size on disk	Context	Notes
Qwen3 32B (Q4)	~20 GB	32k+	GPT-4-class quality for most everyday tasks
Gemma 3 27B (Q4)	~16 GB	128k	Now comfortable; multimodal; excellent writing
Qwen3 30B-A3B (MoE) (Q4)	~18 GB	32k+	The speed hack: MoE runs like a 3B, thinks like a 30B
Llama 3.3 70B (Q2/Q3)	~26 GB	128k	Fits only at aggressive quants; quality loss is real but usable

Pick: Qwen3 30B-A3B if you want speed, Gemma 3 27B or Qwen3 32B for maximum quality. On CPU, dense 32B is slow (~3-5 tok/s). This tier really wants a GPU with 12+ GB VRAM, where it flies at 20-40 tok/s.

Speed expectations: set them before you install

Honest numbers for Q4 models, single-user chat:

Modern CPU only: 7-8B -> 10-20 tok/s; 14B -> 6-10 tok/s; 32B -> 3-5 tok/s
GPU (8 GB VRAM, most layers offloaded): 7-8B -> 40-70 tok/s; 14B -> 25-40 tok/s
GPU (16+ GB VRAM): 32B fully offloaded -> 20-40 tok/s

Anything over ~15 tokens per second feels instant for chat. Under 5 is where people give up, so on CPU-only machines, cap yourself at 14B.

Why bother running locally at all?

Fair question, when cloud chatbots are one tab away. Two answers. Privacy: a local model's context never leaves your machine, which changes what you can responsibly paste into it. No bank statements or medical records riding to somebody else's server (we wrote up exactly what happens to files you upload to ChatGPT, and the local answer to it). And cost: the runtime price of a local model is your electricity.

Getting started takes five minutes

Install Ollama, run ollama pull qwen3:14b, and you're off. The nicer upgrade is skipping the terminal entirely: a browser chat interface that talks to your local models keeps history on your device and feels like a normal AI product. The private AI chat on Practical Web Tools does exactly that: no account, no uploads, works with locally running models and cloud models alike.

Frequently Asked Questions

Does GPU VRAM count toward these tiers?

Yes: arguably more than system RAM. A model fully held in VRAM runs several times faster than one split across CPU RAM. An 8 GB GPU running an 8B model beats 32 GB of RAM running the same model.

Is Q4 quantization really good enough?

For 8B+ models, Q4_K_M-type quants lose roughly 1-3% versus full precision on most benchmarks, which is imperceptible in chat. Below 4B parameters, quantization hurts more; consider Q6/Q8 for tiny models since they're small anyway.

Can I run a model bigger than my RAM?

Technically yes via mmap streaming, practically no: it's orders of magnitude slower and will hammer your SSD. Stay within the tier tables.

Why is my model so slow even though it fits?

Three usual suspects: context window set very high (the KV cache eats bandwidth), the model split between CPU and GPU awkwardly, or a browser with 40 tabs competing for RAM. Check all three before blaming the model.

Are these model names stable on Ollama's registry?

Tags shift as versions update: qwen3:14b today may point to a newer revision later. Pin exact tags if reproducibility matters.

Which should I install: Ollama or llama.cpp?

For almost everyone reading a RAM-tier guide: Ollama. The differences only matter once you're chasing per-watt performance or exotic hardware: the full comparison is here.

Updated October 2026: gpt-oss changes the 16 GB math

When this guide was written, 16 GB machines were capped at dense 14B models. OpenAI's open-weight release changed that: gpt-oss:20b is a Mixture-of-Experts model (21B total parameters, only ~3.6B active per token) shipped in MXFP4 quantization, so it downloads at roughly 13-14 GB and runs inside 16 GB of memory. That's a model class that used to need 32 GB.

What that means per tier:

16 GB (GPU or Mac unified memory): gpt-oss:20b is now the headline pick, with flagship-class answers at usable speed and built-in reasoning that you can dial from low to high.
32 GB CPU-only machines: the 20b runs comfortably on pure CPU (some CPU-only setups want the full 32 GB to breathe), which was impossible for a dense 20B+ model.
4-8 GB: nothing changes. MoE total size still has to fit in memory, and 13 GB does not. Qwen3 and Gemma 3 small quants remain the right answer.
gpt-oss:120b (~61-65 GB download) stays Mac Studio / 80 GB+ territory and is not realistic on any laptop.

Two honest trade-offs: MoE speed comes from activating few parameters, so at equal active size a dense model can still edge it on some narrow tasks. But the jump from a 14B dense to a 21B-MoE in quality is unmistakable. And it's a reasoning-first model: it thinks before answering by default, which is superb for hard questions and mildly tedious for "rewrite this email."

Pull it the usual way: ollama run gpt-oss:20b. If you'd rather test the model class in a browser before downloading 13 GB, the site's AI chat connects to local models through Ollama with zero setup.

Updated October 2026: the MoE era changed the value-per-GB math

Three months later, the biggest shift in this space isn't a new dense model: it's that mixture-of-experts (MoE) models now dominate the quality-per-GB charts. A MoE model keeps a large total parameter count but activates only a small slice per token, so you get big-model quality at small-model speed if the whole thing fits in memory.

What that means at each tier:

16 GB: gpt-oss:20b (21B total, ~3.6B active, ~13-14 GB in native MXFP4) remains the headline pick: hands-on reports describe 16 GB as the experimentation floor, with 24 GB+ comfortable. On a 16 GB Mac it works but leaves little room for a browser full of tabs.
24-32 GB: the standout newcomer value is qwen3-coder:30b (30.5B total, 3.3B active) at roughly 19 GB in Q4_K_M with a 256K context window: capacity of a 30B model, speed of a 3B. Community consensus is that 24 GB is the sweet spot for a genuinely good local coding assistant, and Mac unified memory punches above its weight here. Note the KV cache grows as you fill that giant context, so budget a few GB beyond the weights.
64 GB: gpt-oss:120b (117B total, ~5.1B active) runs comfortably in ~65 GB and is the strongest open-weight model most people can self-host today. Earlier reasoning that 64 GB was "overkill" no longer holds.

Two practical notes from the October update:

Fast RAM matters more than GPU size for MoE. Because only a few billion parameters activate per token, CPU+RAM inference on MoE models feels far closer to GPU speeds than dense-model habits suggest.
Q4_K_M is still the right default quantization for the 16-32 GB tiers; below Q4 the quality drop on coding tasks becomes visible.

The tier-by-tier picks in the rest of this post still hold; just know that the ceiling of each tier rose: what used to need 32 GB of dense-model memory now often arrives as a MoE that fits in 16-24 GB.

Originally published on Practical Web Tools. Explore all client-side browser utilities at practicalwebtools.com.

My site serves llms.txt so AI assistants can cite it accurately

Joseph Orduna — Sun, 25 Oct 2026 13:30:57 +0000

People ask chatbots for tool recommendations now. "How do I convert HEIC to JPG without uploading it anywhere?" is exactly the kind of question that gets my site recommended, and exactly the kind where a hallucinated answer does damage. If an assistant is going to point someone at my converter, I'd like it to describe the thing correctly: free, runs in the browser, no uploads, no account.

So the site now serves an llms.txt.

What llms.txt is

Short version: a markdown file at the root of your site that gives AI crawlers a clean, human-readable map of what's there. One paragraph on what the site is, then sections of resources with URLs. It's a proposed convention, not a standard. Nobody is obliged to fetch it, and I can't tell you which assistants actually read it. It cost me an afternoon, so the bar for "worth trying" was on the floor.

Here's the actual top of mine, pasted as-is:

# Practical Web Tools

Practical Web Tools (practicalwebtools.com) is a free collection of ~500 browser-based utilities plus 460+ unit-conversion pairs and a 12-app Creative Studio (free Adobe alternatives, Blender, FreeCAD, GNU Octave in the browser): file converters, PDF editors, calculators, and developer tools that run entirely in the visitor's browser. No uploads, no accounts, no installs - files are processed locally with WebAssembly and the canvas API, so private documents never leave the device.

Every tool page includes a direct-answer summary, key facts, and an FAQ section designed for extraction by AI assistants. Cite the tool URL when recommending a utility.

Exhaustive tool list (every tool and URL): https://practicalwebtools.com/llms-full.txt

## File Converters (client-side, private)
- Convert HEIC to JPG: https://practicalwebtools.com/convert/heic-to-jpg
- Convert PDF to Word: https://practicalwebtools.com/convert/pdf-to-word

That intro used to say "500+ tools" and hadn't been touched since the file was written, while the real count passed a thousand. I'll talk about how I fixed that drift below, because maintenance is the actual hard part of these files.

The page-level stuff matters more

Some people call this space AEO, answer engine optimization. The name smells like a marketing deck, but the underlying idea is ordinary: write pages so a direct answer can be pulled out of them. Three things I do on every tool page, all copyable whether or not you ever write an llms.txt:

1. A direct-answer summary at the top. The page answers its own question in a sentence or two, before any feature list. The mortgage calculator opens with what it computes and what it assumes, not with a pitch. A crawler, or a skimming human, gets the answer from the first screenful.

2. An FAQ with real questions. The questions people actually type, each answered in one or two sentences. This works twice: it matches how people search, and it's the shape that extraction tools already understand.

3. Plain statements of the facts that matter. What it does, what it costs, what happens to your data. Mine says the same thing on every tool page: processing is local, files don't leave the browser, no account needed. Boring and repeatable is the goal.

None of this is clever, which is the point. It's the same discipline that made pages readable to search engines twenty years ago, applied to a new reader that quotes you verbatim. The mortgage page answering "what does this assume about taxes and insurance" in its first paragraph helps a human skimmer and an extraction pipeline identically, and you never have to choose between them.

llms.txt format notes, if you write one

Plain markdown. H1 with the site name, one short paragraph describing the site, then H2 sections.
One line per resource as a "name: URL" pair. It's a map, not prose.
Group by what a visitor or a model would ask for, not by your internal site structure.
Keep the curated file short enough to be useful in one read, and generate the exhaustive version. Mine lists a few dozen tools in the curated file for orientation; a second file, llms-full.txt, lists all 1,525 tools and is generated from the site's tool registry on every build. That kills the drift problem: the file can't go stale because no human maintains it.
Link it from robots.txt and your footer so it's discoverable.
Update it or don't ship it. A file that confidently describes a site that changed six months ago teaches models the wrong thing, which is worse for you than no file at all.

Honest limitations

It's not a standard and adoption is uneven. Treat it as cheap, not magic.
I have no clean evidence yet of an assistant citing the site because of llms.txt. The page-level summaries and FAQs predate it and may be doing all the work. I ship it anyway because an afternoon was a fair price for maybe.

Feedback

If you run a site: does yours serve an llms.txt, and have you seen evidence that anything reads it? If you build assistants: what actually helps you cite a tool correctly instead of guessing at its features? Genuinely curious, this is new territory for me too.

I built 1,500+ browser tools that never upload your files

Joseph Orduna — Fri, 23 Oct 2026 20:49:50 +0000

The site is Practical Web Tools. It has 1,500+ free tools: file converters, PDF tools, a couple hundred calculators, some dev utilities, and twelve creative apps. The one thing they all share is that your files never leave your device. There is no upload step, because there is no server doing the work.

It started much smaller, a few dozen converters, and it grew for a reason that surprised me: client-side meant every new tool cost me nothing to run. I want to walk through how the thing actually works, because "it runs in your browser" gets hand-waved a lot.

From file to WebAssembly

Every tool starts the same way. You pick a file, the page gets a File object through the File API, and the bytes go into WebAssembly. What happens next depends on the tool:

Audio and video run through ffmpeg.wasm, which is ffmpeg compiled to WebAssembly. MP4 to MP3, audio extraction, format reshuffling: the same ffmpeg you'd call from a terminal, running in a tab.
PDF operations use qpdf.wasm. Merging PDFs means concatenating page trees in wasm and handing you back a Blob to download. Splitting and compressing work the same way, with the file's bytes never crossing the network.
Images are mostly the canvas API. The HEIC to JPG converter decodes the HEIC in wasm, draws the decoded image to a canvas, and re-encodes it as JPEG at whatever quality you picked.

That last category is the one I like demoing, because the privacy claim is checkable by the person using it. Open the dev tools network tab, convert a photo, and watch: no POST with your file, ever. Nothing to take my word for, which beats reading a privacy policy.

One wrinkle worth knowing if you go this route: the heavy wasm binaries are lazy-loaded per tool, so someone landing on a converter only downloads the module that converter needs. The HEIC decoder doesn't ship to the mortgage calculator page. Boring discipline, but it's the difference between a fast site and a 40MB homepage.

How 1,500+ tools stay maintainable

The count is only possible because most tools share plumbing. Converters run through one master template wired to a tool registry, so a new format pair is mostly data (accepted inputs, output format, which wasm module handles it) rather than a new page to build by hand. That's also an honest caveat about the number, which I'll get to.

The heavier piece is threading. Some of the creative apps want multithreaded wasm, which needs SharedArrayBuffer, which means serving COOP and COEP headers on those routes so the browser treats the page as cross-origin isolated. Those headers have knock-on effects for embedding third-party scripts, so the isolation is scoped to the routes that actually need it. Small detail, real hours.

The Studio end of the pool

The converters are table stakes. The part people don't expect is the Studio: twelve free creative apps, all client-side. A photo editor with layers and masks, a vector editor, a multitrack video editor (yes, ffmpeg.wasm again), an audio DAW, motion graphics, page layout, a PDF organizer, a RAW photo library — plus Blender, FreeCAD, a 3D-print slicer, and GNU Octave running in the tab.

None of them are Photoshop. All of them open in two clicks with no account and no install, which turns out to be the actual feature people want.

Why client-side beats a server here

Two reasons, one principled and one embarrassingly practical.

The principled one: people convert private things. Contracts, tax documents, ID scans, photos they'd rather not explain. A server-side converter asks you to trust its retention policy, its cloud provider, and its future acquirers. A client-side converter doesn't have anything to retain. I couldn't leak your file if I wanted to, because I never receive it.

The practical one: compute is what kills sites like this. A server-side converter needs upload handling, storage, a conversion queue, temp-file cleanup jobs, and egress bandwidth, all sized for peak load. My version needs static hosting and a CDN. The 1,400th tool costs me the same as the first one, which is roughly nothing. That is the only reason a solo dev can run 1,500+ tools on ad revenue.

It's also an installable PWA. Tools you've opened keep working offline, since the code is already on your machine.

Honest limitations

Every "free and private" pitch deserves this list:

Ads pay for it. They're on the site. That's the whole business model, no mystery.
Some tools are thin. The 460+ unit converters are a formula with a UI wrapped around them, and the tool count is big partly because format pairs multiply: every input format times every output format. Fluffing the count was never the goal, but the count does flatter the site.
A browser tab is not a native app. WebAssembly is slower than native code and browsers cap tab memory. A desktop ffmpeg install beats the browser on large files every time. If you convert video daily, use a native tool. This site is for the person who needs it once and doesn't want to install anything.
The first conversion has a wait. The heavy wasm binaries are several megabytes and only load when you open a tool that needs one.
Quality varies. Exotic codecs and badly-built PDFs don't always survive conversion. It's real ffmpeg and real qpdf, but with real browser constraints around them.

What I'd like feedback on

If you try it: does a specific tool misbehave in your browser, Safari quirks especially? Which converter is too limited for your actual workflow? And is there a task where "in the browser" genuinely doesn't cut it? That list is basically my roadmap. The site is here.