The usual diagnosis is "the machine hates my font", and the usual fix people reach for is installing that font on every machine that touches the file. That works until it doesn't — until a collaborator, a print shop, or a firmware update gets in the loop. The robust fix is older than laser cutters themselves: stop shipping text, ship outlines.

Why text is a liability inside an SVG

An SVG <text> element doesn't contain letterforms. It contains a reference to letterforms: the font family name, a size, and a string. Rendering is delegated to whatever font engine opens the file. That's fine on the web, where you can ship a webfont alongside. It's a liability everywhere else:

• The receiving machine doesn't have the font, so it substitutes one — different metrics, different look, sometimes catastrophic reflow.
• The machine does have the font, but a different version with different glyph outlines.
• The software rasterizes or traces text with its own rules, and single-line engraving fonts get filled-font treatment.
• Licensing: some font licenses don't permit embedding or conversion at all.

A path, by contrast, is geometry. M 10 10 L 20 10 L 20 20 Z renders identically on a 2008 vinyl cutter and a 2026 fiber laser. Converting text to paths — outlines, in print terminology — removes the font from the equation entirely.

When to convert (and when not to)

Convert to paths when the file leaves your machine for machines, cutters, plotters, engravers, print shops, or when it will be embedded in something long-lived (a logo, a hardware panel legend, a product engraving spec).

Keep live text when the words must stay selectable, searchable, or translatable — documentation, wireframes, anything a screen reader should read. Outlined text is dead text: no copy-paste, no find, no accessibility tree.

One practical note: convert last. Do all your editing and sizing while the text is still text, because once it's outlines, fixing a typo means re-typing the word and converting again.

How the conversion has to work

A naive approach renders each string as one blob. Real text-to-path conversion has to work per glyph, because that's how SVG text actually lays out:

• Per-glyph placement, not per-string. Each letter becomes its own path, positioned exactly where the text engine would have put it — including kerning pairs. A blob loses the ability to re-cut a single letter or reorder anything.
• Real text metrics. The converter has to understand font units and em squares, and emit coordinates in units that survive any viewBox — otherwise the outlines land at the wrong scale and the whole job cuts small.
• Everything visual survives the swap. Fill, stroke, opacity, transforms on the text element — the outlined version should be pixel-identical to the text version when rendered side by side.
• Honest failure modes. A converter should tell you when it can't map a glyph instead of silently dropping it. A missing Z on a contour or a literal NaN in path data means a gap in the cut line or a toolpath error on the machine.

The one-command version

SVG Editor has a built-in Text to Path tool that does this conversion entirely in your browser: load the SVG, select the text, convert, download. Nothing is uploaded, nothing needs an account, and you get a side-by-side preview so you can verify the outlines match before you send the file anywhere. The full reasoning — the pain points, the per-glyph mechanics, the failure modes — is written up in SVG text to path: why and how.

After the conversion: the machine-ready pipeline

Once your text is outlined, the file is geometry-only and safe to hand to anything. The usual next steps for cutter workflows:

1. Clean up the geometry. Optimize the SVG — redundant nodes and editor metadata confuse CAM software more often than people expect.
2. Export to a machine format. Convert directly to G-code for CNC and diode lasers, or DXF for laser cutters and plasma tables that expect CAD interchange. Both expect outlines — never live text.
3. Preview before you cut. A quick render pass in the SVG preview tool catches an empty result before you find out with a wasted sheet of material.

The pattern is always the same: text is for humans and editors, paths are for machines. Convert once, at the end, and the file becomes portable in a way no font installation scheme can match.

This isn't something you can patch with a PNG swap. There is no rel="icon-dark" in HTML. But there is a clean fix, and it fits in a single file.

The trick: CSS inside your SVG favicon

SVG favicons can embed a <style> block, and browsers apply it — including media queries. That means one favicon.svg can restyle itself based on prefers-color-scheme:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 32 32">
  <style>
    @media (prefers-color-scheme: dark) {
      .bg { fill: #101418; }
      .logo { fill: #f4f6f8; }
    }
    .bg { fill: #ffffff; }
    .logo { fill: #101418; }
  </style>
  <rect class="bg" width="32" height="32" rx="6"/>
  <path class="logo" d="..."/>
</svg>

The browser resolves the media query against the user's OS or browser theme at render time. Light theme → light background, dark strokes. Dark theme → dark background, light strokes. No JavaScript, no user-agent sniffing, no second file to keep in sync.

Wire it up with a proper fallback

Declare the SVG first, the classic .ico second:

<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="icon" href="/favicon.ico" sizes="32x32">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

Browsers that understand SVG favicons pick the first; everything else falls back to the .ico. Keep that fallback — as of 2026 every evergreen browser supports SVG icons, but crawlers, feed readers and some embedded webviews still grab .ico.

Two dark-mode details people miss

1. The tab strip color is separate from your icon. The theme-color meta tag controls the browser UI tint:

<meta name="theme-color" content="#ffffff" media="(prefers-color-scheme: light)">
<meta name="theme-color" content="#0b0d10" media="(prefers-color-scheme: dark)">

If your icon now flips but the toolbar stays light, this is the missing half.

2. Safari on iOS flattens transparency onto black. Your crisp transparent PNG apple-touch-icon becomes a dark blob on a dark-mode home screen. Bake your brand background into the export. Safari's macOS pinned-tab icon is its own rabbit hole (mask-icon and its support matrix) — worth a dedicated read.

A few honest limitations

• prefers-color-scheme inside SVG icons works in Chrome, Edge, Firefox and Safari for favicon.svg. Some third-party clients render the SVG without applying the media query — they show your light-theme default. That's exactly why the default styles should be readable on their own.
• If your brand mark is genuinely mid-gray, it may be adequate in both themes. Adaptive icons matter most for black, white, or low-contrast marks.
• Don't ship a 40 KB styled SVG where a 1 KB one works. Gradients and filters bloat what should be the smallest asset on your page.

The 30-second audit

Want to know what your site currently serves in each theme?

1. Open your site, toggle OS dark mode, look at the tab strip. If the icon vanishes, you're shipping a non-adaptive asset.
2. Check what your <link rel="icon"> tags actually resolve to with the Favicon Checker — it reads the live page and reports every icon you declare.
3. If you're starting from a logo image or a brand name instead of an SVG, the SVG favicon generator and the text-to-favicon tool export a clean favicon.svg you can paste the <style> block into — free, runs entirely in your browser.

Full walkthrough with the complete SVG template and the JS fallback for legacy browsers: Favicon Dark Mode: Adaptive Icons for Light & Dark.

If you have jq installed, it's a 10-second one-liner. If you don't — Windows admin box without admin rights, a locked-down corporate laptop, a client's machine you can't install anything on — your options have traditionally been: copy the JSON into a random web playground (and hope it doesn't store it), or squint at it in an editor.

There's a third option now: the actual jq binary, compiled to WebAssembly, running entirely inside your browser tab.

Same filter language, no installation

We shipped real jq — not a lookalike interpreter — at JSON Formatter App. The jq-wasm build compiles jq 1.8.2, so the filter language behaves exactly like the CLI you know:

# failed orders with their error codes
.map(select(.status == "failed") | {id, code: .error.code})

# group users by role, count each group
group_by(.role) | map({role: .[0].role, count: length})

# top 5 endpoints by latency
sort_by(-.latency_ms) | .[0:5] | map({endpoint, latency_ms})

Type a filter, see results live as you type, and every transform is one Ctrl+Z away — which matters more than it sounds when you're five refinements deep into a gnarly filter.

Why WebAssembly instead of a JS reimplementation

A handful of sites reimplement jq syntax in JavaScript. They're fine until they aren't: edge cases in string interpolation, @base64, limit, date functions, or streaming behavior drift from real jq, and your filter silently returns something almost right. With the compiled binary there's no drift to audit — it's jq's own C code answering.

When JSONPath is the better hammer

jq is for transformation; JSONPath is for extraction. If your question is "give me every $.orders[*].items[*].sku", JSONPath is shorter to write and shows match counts with unwrapped single results. The panel flags honest errors instead of silently returning [] — the classic JSONPath failure mode that makes you think your path matched nothing when actually it was malformed.

The part nobody talks about: where your payload goes

A jq playground that runs your filter server-side has just received your JSON. If that payload is a production response — user records, tokens, internal IDs — you've shipped it to a stranger's logs. This isn't hypothetical; we covered what the CodeBeautify leak exposed in detail.

The whole point of running jq in WASM is that after the page loads, zero network requests leave the tab. Don't take my word for it — open DevTools → Network, clear it, paste your payload, run a filter. That 10-second audit works on any tool; here's the full checklist for evaluating whether an online formatter is safe with sensitive data.

Quick reference

Try it at jsonformatter.app — the transform panel sits next to the formatter and validator, so you can debug the syntax error and transform the payload in the same tab.

What's actually happening

Your router has finite buffers. When a download saturates the line, packets (including those tiny latency-sensitive ones carrying your voice) queue up behind bulk traffic. The result: ping goes from 8 ms to 300+ ms while the line is busy. Speed tests never show this, because they measure speed while idle.

The fix starts with measuring it, which most tools don't do. SpeedPulse is a free browser-based speed test that measures idle latency, jitter (variation in ping), and bufferbloat (how much latency grows under load), then grades each A+ through F in plain English. No signup, no app, no cookies.

How to diagnose in 25 seconds

1. Open speedpulse.tech and run a test while your network is idle — note the bufferbloat grade.
2. Start a big download in another tab (or have someone stream 4K) and run it again.
3. If your latency under load jumps 10x, congratulations: it's bufferbloat, not your ISP's bandwidth.

While you're at it, check whether your ISP is gaming the test: SpeedPulse pings 8 independent CDN edges after each test. If the speed-test server is dramatically faster than every other edge, your ISP is likely prioritizing speed-test traffic. There's a full write-up of that methodology on the SpeedPulse blog.

What actually fixes it

• Enable SQM/QoS on your router (OpenWrt's cake/sfq or a Smart Queue on stock firmware) — this is the single biggest win, it keeps buffers short so bulk traffic can't starve latency.
• Prefer wired for the machine doing calls; Wi-Fi adds jitter even on a clean line.
• Cap background sync (cloud drives, Steam, OS updates) during meetings.
• If your ISP can't deliver sane latency under load even with SQM, that's a real signal when choosing providers.

If you want a systematic walkthrough, I put together a free "why is my internet slow" checklist covering symptoms, measurement, and fixes.

Why I built this

I'm the author of SpeedPulse — I built it because raw Mbps numbers hide the problems people actually feel: stuttering calls, rubber-banding games, slow page loads on an "idle-fast" line. It also shows verdicts for streaming, gaming, and video calls instead of making you interpret raw numbers. If you compare tools, I also published how it stacks up against Ookla, Fast.com and Waveform, and a plain-English explainer of what bufferbloat actually is.

Run one test today — if your bufferbloat grade is C or worse, the SQM fix above will genuinely change your calls. Happy to answer methodology questions in the comments.