DEV Community: FF

Your AI-Generated SVG Won't Render: The Same 8 Defects Every Time

FF — Mon, 02 Nov 2026 00:45:19 +0000

You asked a model for an SVG. The code looks right — tags, paths, colors, all plausible. You paste it into a file, open it in a browser, and get... a blank rectangle. No error, no warning, nothing.

If this happens to you regularly, it's not bad luck. SVG is XML, and XML is unforgiving in a way HTML never is. A browser reading HTML will patch over a missing quote or an unclosed tag and render what it can. A browser reading SVG does none of that: one syntax slip and the whole document is rejected — usually silently.

Language models generate SVG the way they generate everything else: token by token, plausibly. They pattern-match on millions of examples without running an XML validator or a geometry engine. So they fail on exactly the details a validator would have caught — and they fail in the same ways, over and over. Here are the eight defects behind almost every broken AI-generated SVG I've seen.

The 8 defects

1. Missing xmlns attribute. The #1 killer. Without xmlns="http://www.w3.org/2000/svg" the browser treats the file as generic XML. It may render inline in an HTML page, then fail as a standalone file or inside an <img> tag — which makes it look like a caching bug. Models forget it constantly.

2. Missing or invented viewBox. No viewBox, and the browser has no idea which part of the coordinate system to show. Or the model writes viewBox="0 0 24 24" and then draws at x="150" — every shape lands off-canvas and you get an empty frame.

3. Shapes translated out of view. AI loves decorative transform="translate(350, 280)" guesswork. The markup is valid, the preview is blank, and nothing tells you the artwork is sitting just outside the frame.

4. A raw & in a label. SVG is strict XML. A label like Tom & Jerry with a bare unescaped & invalidates the entire document. One character, whole file dead.

5. NaN and Infinity coordinates. Models do arithmetic in public: d="M 10 10 L NaN 50" or a radius of Infinity. The path is syntactically present and renders as nothing.

6. Unclosed or misnested tags. Truncated output, a <g> that never closes, an attribute missing its quote. XML parsers are all-or-nothing — one structural slip and nothing renders at all.

7. Chat prose and code fences. "Sure! Here's your logo:" ... `svg ... "Let me know if you'd like adjustments!" Paste that into a file and you have prose, fences, and markup layered together. Browsers don't strip any of it for you.

8. Everything fill="none". The model styles each shape with fill="none" and forgets to add a stroke. The file parses, the shapes exist, the image is empty. This one fools people the most because the SVG technically "works".

Defects 1–6 kill the file outright at parse time. 7–8 are sneakier: the file renders, it just renders empty — worse to debug because there's no error message to search for.

The 30-second diagnosis

Before fixing anything, figure out which defect you have:

Open the file and search for xmlns. Missing? That's defect 1.
Check the viewBox against the largest coordinates in the file. Drawing at 400 but viewing 0–24? Defect 2 or 3.
Look for NaN, Infinity, or a bare & outside entities. Defects 4 and 5.
Text at the top of the file that isn't markup? Defect 7.
Everything has fill="none" and no stroke? Defect 8.

Or skip the manual pass: paste the raw chat output — prose and fences and all — into SVG Repair. It extracts the real markup, repairs the XML, adds the missing xmlns and viewBox, zeroes out NaN coordinates, expands the canvas to include off-screen shapes, makes invisible shapes visible, and shows you an itemized report of every defect next to a before/after preview. It actually renders the repaired file and checks it paints a non-empty image before claiming success. Everything runs client-side — the file never leaves your browser.

Prevent it at the source

Repairing is faster than regenerating, but the cheapest fix is an SVG that isn't broken. Four lines added to the prompt eliminate most defects:

"Output only the raw SVG markup, no explanation, no code fences." — kills defect 7 entirely.
"Include xmlns and a viewBox that matches the coordinate range you draw in." — kills defects 1 and 2.
"Draw all shapes inside 0 0 512 512. Use no transforms." — kills defect 3.
"No <script>, no CSS classes, no text — convert text to paths." — kills the surprise below.

One more thing AI SVGs smuggle in: scripts

Models occasionally emit <script> tags, onload handlers, or foreignObject blocks — sometimes because you asked for animation, sometimes out of nowhere. That matters beyond rendering: an SVG carrying scripts becomes a live XSS vector the moment someone opens it directly or inlines it into a page. If you're accepting SVGs from users, or embedding AI output into anything public, strip active content before it ships. The repair pipeline above strips it by default.

When it renders again, keep going

A repaired file is a working file, not a finished one. AI output carries redundant precision and empty groups that a proper SVG optimizer typically shaves 30–60%. Whole icon sets can be repaired and converted in batch. And when the geometry is almost right, a free browser-based SVG editor lets you fix it visually — select and move shapes, edit text, adjust fills and strokes — without installing anything or uploading the file anywhere.

The full write-up with more prompt examples is here: Why your AI-generated SVG doesn't render.

The 2026 Favicon Checklist: every size your site actually needs

FF — Sun, 01 Nov 2026 10:36:52 +0000

A few years ago "add a favicon" meant dropping one favicon.ico in your site root. In 2026 that same site will look broken in at least four places: blurry in a retina browser tab, a generic globe in Google search results, a white square when an Android user saves it to their home screen, and a black blob on an iPhone.

The fix isn't hard — but the requirements have quietly multiplied. Here's the complete size set that actually matters in 2026, why each one exists, and a copy-paste HTML block at the end.

The 2026 favicon checklist

Size	File	Where it's used
16×16	`favicon-16x16.png`	Classic browser tabs
32×32	`favicon-32x32.png`	Retina tabs, Windows taskbar
48×48	inside `favicon.ico`	Windows site icons, older browsers
180×180	`apple-touch-icon.png`	iOS home screen, Safari pinned tabs
192×192	`android-chrome-192x192.png`	Android home screen, Chrome PWA
512×512	`android-chrome-512x512.png`	PWA splash screen
vector	`favicon.svg`	Modern browsers, dark-mode adaptive icons

Six files. Not optional if you care about how your site presents on mobile and in search.

Why each size survives

16×16 + 32×32 — the browser tab. 16×16 is the legacy default; 32×32 is what actually renders on high-DPI displays. Ship both. A tab icon that's only 16×16 gets smeared by the browser's upscaler on any modern laptop.

48×48 — inside the .ico. The .ico container can bundle multiple sizes in one file (16/32/48 is the common bundle), which is why a well-built favicon.ico is still the most compatible single file you can ship. Windows site pins and plenty of crawlers read it first.

180×180 — Apple's tax. iOS ignores your favicon entirely. When a user taps "Add to Home Screen", Safari reads exactly apple-touch-icon.png at exactly 180×180. One more trap: iOS composites transparency onto black — export on your brand background or your logo gets a black box.

192×192 + 512×512 — Android & PWA. These are read from site.webmanifest. 192 is the Android home-screen icon; 512 powers the full-screen splash when your PWA launches. Ship a 512 source and downscale — never upscale, it shows.

SVG — the modern bonus. Every evergreen browser takes favicon.svg, it scales everywhere, and it can embed a prefers-color-scheme media query so your icon adapts to dark browser themes (worth its own post).

The Google search angle people forget

Google shows a favicon next to your result on mobile (and increasingly desktop). If your icon declaration is broken or too small, Google shows a generic globe — and search results with a real icon get measurably more clicks than the globe. Google recommends a square image ≥48×48, ideally multiples of 48, reachable at the root. This is one of the few branding fixes that directly affects CTR.

The one source-of-truth rule

Maintain one square master ≥512×512 (1024×1024 ideal) and derive everything from it. Hand-maintained icon folders are where stale sizes and 404s come from — treat favicon files as build output, not design artifacts.

Copy-paste block

<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="icon" href="/favicon-16x16.png" sizes="16x16">
<link rel="icon" href="/favicon-32x32.png" sizes="32x32">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">
<link rel="manifest" href="/site.webmanifest">
<meta name="theme-color" content="#ffffff">

The 30-second audit

Not sure what your site currently serves? Two moves:

Check what's declared vs. what resolves — the Favicon Checker reads your live page and reports every icon it finds.
Generate the full set from one image — upload one square PNG to favicon.one and get a ZIP with every size above, the .ico, the SVG, the manifest, and ready-to-paste HTML. Free, no signup, all in-browser.

If you only have a JPG or an odd-size PNG, the PNG → ICO converter handles the legacy part.

Complete reference with per-platform details: Favicon Size Guide: Every Dimension You Need in 2026.

I stopped pasting API responses into online JSON formatters — here's the 30-second audit I run instead

FF — Sun, 01 Nov 2026 01:44:28 +0000

In November 2025, watchTowr Labs disclosed that CodeBeautify.org — one of the largest developer-tool sites on the internet — had been exposing user-pasted data through a public "Recent Links" feed. Not a hypothetical: API keys, SSH private keys, and cloud credentials that developers pasted in to "just format this quickly" were reachable by anyone who knew where to look.

If you've ever pasted a production payload into an online formatter, this one's for you.

The uncomfortable truth about "online tools"

Most web-based formatters are not actually processing your data in your browser. Many POST your payload to a backend, format it server-side, and hand it back. Some store pastes to make "shareable links" — and shareable means enumerable.

We put together a full technical breakdown of what happened, what was exposed, and the mechanics behind it:
The CodeBeautify data leak, explained

The 30-second audit (run this on any web tool)

Before trusting any online tool with a real payload:

Open DevTools → Network tab, filter to Fetch/XHR
Clear the log
Paste your JSON and hit format
Watch the network panel

Any request whose payload contains your data = it left your machine. Doesn't matter what the landing page says about privacy. The network panel doesn't lie.

Second check: load the page, turn off Wi-Fi (or use DevTools' offline throttling), and see if the tool still works. A genuinely client-side tool keeps working with zero connectivity. One that "phone home" dies on the spot.

What a real client-side pipeline looks like

For the past year I've been using JSON Formatter App precisely because you can do this audit on it and come up clean — after the initial page load, everything runs in the browser: formatting, validation, transforms, the lot. No account, no cookies required, paste and go.

The parts I actually use daily:

Validation that names the error. Chrome 114+ changed how V8 reports JSON syntax errors, which silently broke a bunch of tools that parsed V8's error strings. A scanner written against the spec instead survives browser updates, and gives you plain-English errors with exact line/column plus jump-to-error: why JSON validators should name the error
Real jq in the browser. Not a jq-lookalike — actual jq compiled to WebAssembly: map, select, sort_by, group_by, object construction, with live preview as you type: jq + JSONPath transform panel
One-click auto-repair for the trailing-comma / single-quote / comment mistakes we all make when hand-editing config

And if you want the general checklist for evaluating whether a formatter is safe to use with sensitive payloads — the offline test, the network audit, what to look for in the privacy policy: what makes a JSON formatter actually secure

The habit worth keeping

It's not "never use online tools" — it's know which tier of data you're pasting:

Never: credentials, tokens, customer data, anything from prod → local tool or editor only
Gray zone: internal payloads, staging responses → only tools that pass the network audit
Fine: public API samples, tutorial snippets, your kid's Minecraft JSON → whatever's fastest

The CodeBeautify leak wasn't malice — it was a "shareable links" feature meeting real-world data. Every tool with a paste box and a server is one config change away from the same outcome. Audit before you paste, not after.

Full disclosure of the incident and what was exposed: CodeBeautify data leak explained — and yes, run the audit on our tool too. That's the point.

Your internet isn't slow — it's bufferbloat. Diagnose it in 25 seconds.

FF — Sat, 31 Oct 2026 07:26:03 +0000

You pay for 500 Mbps. At 2 a.m. everything is instant. At 7 p.m., when someone starts a game update, your video call turns into a slideshow — and the speed test you run right after still cheerfully reports 500 Mbps.

Nothing is broken. Your speed test just doesn't measure the thing that's actually hurting you.

The number that speed tests don't show you

Raw bandwidth answers "how much data can move per second". It says nothing about how long each tiny packet waits when the line is busy — and that latency-under-load number is what real-time apps live and die by.

That problem has a name: bufferbloat.

Modern routers and modems buffer packets instead of dropping them. That's polite under light load, but when a download saturates your link, outgoing packets — your video call frames, your game inputs — get stuck at the back of a huge queue. Your ping goes from 8 ms to 300+ ms while the download runs. The call stutters. The game desyncs. When the download finishes, everything is magically fine again, which is why it feels haunted.

Jitter is the sibling problem: the variation in your ping between packets. Real-time codecs can hide high latency better than they can hide inconsistent latency.

The 25-second diagnosis

You need a test that measures latency while the line is saturated, not just at idle. Waveform's bufferbloat test is the well-known option.

SpeedPulse is the one I built — free, no signup, no app, no cookies, everything runs client-side. One ~25-second run measures:

Download / upload / idle ping — the usual suspects
Jitter (RFC 3550-style mean difference between consecutive pings)
Bufferbloat — a ping train keeps running during the download and upload phases; the tool reports loaded latency − idle latency per direction and grades the worse one from A+ to F
Plain-English verdicts for 4K streaming, gaming, video calls and browsing, so you don't have to interpret raw numbers
An 8-CDN cross-check — after each test it pings 8 independent CDN edges (Cloudflare, jsDelivr, Fastly, GitHub, Google, AWS...). If the speed-test server is dramatically faster than the pack, your ISP may be prioritizing speed-test traffic — the classic reason "the test says I'm fine but everything feels slow"
CSV export and a local history chart, all client-side

Reading the grade

Grade	Extra latency under load
A+	< 5 ms
A	< 30 ms
B	< 60 ms
C	< 200 ms
D	< 400 ms
F	≥ 400 ms

If you score C or worse, you've found your problem.

Full disclosure: I built SpeedPulse. The grade scale is the same A+–F scheme Waveform and the bufferbloat.org community use, so results are comparable across tools — I'd rather share a standard than invent a flattering one.

The fixes that actually work

In order of effectiveness:

Enable SQM with fq_codel/CAKE on your router (trivial on OpenWrt; many stock firmwares ship a basic "QoS"). Smart queue management keeps buffers short so latency stays flat even at full load. This is the fix — A+ grades come from this.
Cap your speeds ~5–10% below your ISP rate in the SQM settings. Counter-intuitive but correct: queues then form inside your router, where SQM controls them, instead of inside the ISP's modem, where they don't.
Fix the upload direction first. Skinny upstreams bloat first — video calls die on upload saturation (cloud backup + call = slideshow). If you can only cap one side, cap upload.
Go wired for the machine that matters. Wi-Fi retransmissions and airtime contention add jitter no router setting can undo.
Check for speed-test favoritism. If only the test's server is fast while every other CDN is slow, the 8-CDN panel makes the mismatch visible — worth raising with your ISP.

For the nerds: how you measure this in a browser

No ICMP, no raw sockets. A browser test times HTTPS round trips with fetch(url, { mode: 'no-cors' }) and performance.now(). no-cors returns an opaque response — no body, no status — but the full network round trip (DNS, TCP, TLS, HTTP) completes, which is all timing needs. Jitter is the mean absolute difference between consecutive samples; bufferbloat is the median loaded latency minus the idle median, measured per direction, graded on the worse of the two.

Full methodology write-up, including the limitations we're honest about: How SpeedPulse measures jitter, bufferbloat and 8 CDN latencies.

Run the test on your line and drop your grade in the comments — happy to help interpret results: speedpulse.tech. Want the long-form bufferbloat explainer (router queue theory, CAKE vs fq_codel)? What is bufferbloat?

How to Create Custom Emojis for Discord and Slack for Free (No Design Skills)

FF — Fri, 30 Oct 2026 17:44:31 +0000

Every server admin and community manager hits the same wall eventually: you need a reaction emoji that simply doesn't exist. The inside joke lands, everyone types "we NEED that as an emoji," and then... nothing, because making custom emoji images sounds like a design job.

It isn't. Here are two free ways to make original emojis in under a minute, plus how to upload them to Discord and Slack.

Option 1: Fuse two emojis into a new one

The fastest route is an emoji "mixer" — it blends any two existing emojis into a brand-new one, no drawing required. EmojiMagic.io's Emoji Mixer does this instantly in the browser:

Pick emoji A (say 🐱)
Pick emoji B (say ☕)
Get the fused result — cat + coffee usually lands somewhere adorable

Every pair works, and you can regenerate until something clicks. No signup, no watermark, works on your phone too.

Option 2: Generate from a text prompt

When you need something no two emojis can produce ("a capybara wearing a hard hat"), use an AI emoji generator instead. On emojimagic.io you type the idea and get four styles back: Apple style, sticker, cute 3D, and flat. Free daily credits, no account needed.

Export a transparent PNG

Both routes give you a transparent PNG download — this matters, because a white box behind your emoji looks terrible on dark mode. The site handles transparency automatically; just hit download.

Upload to Discord

Open your server → Server Settings → Emoji
Click Upload Emoji
Pick your PNG, give it a name in lowercase (e.g. :catcoffee:)
Everyone in the server can now use it — including Nitro users, who can carry it to other servers

Discord resizes anything you throw at it, but square images around 128px look crispest.

Upload to Slack

Workspace name → Customize workspace → Emoji
Add custom emoji, name it, upload the PNG
It's instantly available to the whole workspace

Two quick tips

Test at small size. Your emoji renders at 22px in most chat clients. If the detail disappears, simplify.
Name for discoverability. :catcoffee: beats :image3: — people type names to find reactions.

That's the whole workflow: mix or generate, download the transparent PNG, upload. The emoji your community asked for doesn't need a designer — just a free browser tab.

How Emoji Semantic Search Works: Embeddings, Cosine Similarity, and 310k Vectors in Milliseconds

FF — Thu, 29 Oct 2026 16:56:52 +0000

Type "cozy morning coffee" into our emoji search and it returns breakfast, warm-light and calm-mood emoji combinations — none of which share a single keyword with the query. No synonym table, no hand-tagging. That swap from keyword lookup to meaning-based matching is powered by the most boring-sounding stack in modern ML: text embeddings plus cosine similarity, scanned over ~310,000 precomputed vectors. This is the engineering tour of how it works and what we learned building it.

Keyword tables don't generalize

Classic emoji search is a lookup table: "happy" maps to 😊, and if you type "joyful" you get nothing. Every synonym must be hand-tagged and every phrasing anticipated.

Embedding-based search flips the problem. Instead of matching strings, you match points in a high-dimensional space:

Every query is converted into a vector of numbers.
Every item in the catalog (for us, 310k+ emoji combinations) is also a vector, precomputed ahead of time.
"Similar" simply means "geometrically close" — and geometry generalizes to words the system has never seen.

The embedding pipeline, step by step

We use an open-source multilingual model (BGE-M3, 1024 dimensions). Every text — queries at runtime, the whole catalog offline — goes through the same four stages:

Tokenization — the model sees subword tokens, not words: "cozy morning coffee" → ["co", "##zy", "morning", "coffee"]. Rare words split into known pieces, so the model can embed text it has never seen.
Transformer encoding — each token flows through self-attention layers, exchanging information with every other token. "coffee" absorbs the fact that "morning" is next to it.
Mean pooling — one per-token vector each is averaged into a single 1024-dimension sentence vector.
L2 normalization — the vector is scaled to unit length, landing on the surface of a unit sphere.

That last step is load-bearing. Once every vector has length 1, comparing directions is all that's left.

The math that ranks everything

Cosine similarity measures the angle between two vectors, ignoring length — from −1 (opposite) through 0 (unrelated) to +1 (same direction):

cos(θ) = (q · c) / (|q| × |c|)

Because we normalized everything to unit length, the denominator is always 1 and the whole formula collapses to a plain dot product — one multiply-and-add per dimension. There's also a neat identity that falls out:

|q − c|² = 2 − 2 × cos(θ)

Smaller Euclidean distance and larger cosine similarity are the same statement for unit vectors. Whether your nearest-neighbor code sorts by dot product, cosine, or Euclidean distance, the ranking is identical.

Here's the entire mechanism in three dimensions, small enough to check by hand:

import numpy as np

query = np.array([0.80, 0.60, 0.00])   # "coffee"
combos = np.array([
    [0.70, 0.70, 0.14],                # "hot drink"
    [0.20, 0.30, 0.93],                # "birthday party"
])

cosine = combos @ query / (
    np.linalg.norm(combos, axis=1) * np.linalg.norm(query)
)
print(cosine)   # [0.98 0.34]  -> hot drink wins by a mile

Scale that from 3 dimensions to 1024, and from 2 candidates to 310,000, and you have semantic emoji search.

The lifecycle of one search

Offline, once: embed every catalog item and store its vector alongside its text. Vectors never change until the catalog does, so this cost is paid once — not per search.

Online, every search: embed the query with the same model, compute the dot product against the catalog, sort, return the top 100. Mixing models between index time and query time is the classic bug that quietly destroys result quality — two models produce two incompatible geometries.

Exact scan vs. ANN index

1024 dimensions × 310k vectors is ~318 million multiply-adds per query. That sounds scary and isn't: a tight vectorized loop finishes in well under a second, and an exact scan returns the provably best matches. Most systems switch to approximate nearest-neighbor (ANN) indexes — graph or cluster structures that trade a sliver of recall for an order-of-magnitude speedup — only past a few million vectors. Know your threshold before you reach for the fancy index.

Lessons we learned the hard way

Normalize your vectors at write time — cosine becomes a dot product and rankings stay consistent.
Use one model everywhere. Index and query vectors must share a geometry.
Precompute aggressively. Only the live query should pay the embedding cost.
Watch p99, not the average. Inference has cold starts; warm instances matter more than average speed.
Evaluate with real queries. Cosine scores don't feel like relevance — the only test that counts is whether humans like what comes back.

If you want to see it ranking live, every query on emojimagic.io/text-to-emoji runs exactly this pipeline — this post on our blog has the full worked example, and the site itself is free with no signup if you'd rather throw queries at it than read about them.

Why SVG Files from Figma Are 50–80% Dead Weight (and What to Strip Out)

FF — Tue, 27 Oct 2026 23:52:48 +0000

Every project has at least one multi-kilobyte SVG icon that could have been a few hundred bytes. Design tools write SVG for their convenience, not for the web — and the result is routinely 3–5× larger than it needs to be.

Here are the 7 things making your SVGs bigger than they should be.

1. Editor metadata

<metadata> blocks, rdf:RDF payloads, generator comments — Figma, Illustrator and Inkscape all pad files with data only they read. Browsers never render it.

2. Coordinate precision

74.98399992065430 renders identically to 74.984. Dropping to 2–3 decimals is the single biggest win on path-heavy artwork — often half the file.

3. Empty and nested groups

<g> wrappers that mirror the editor's layer panel but apply no transform or style.

4. Unused defs

Gradients, filters, masks and symbols defined but never referenced by any shape.

5. Editor IDs and attributes

id="Layer_1", data-name, xmlns:serif, style attributes with no visual effect.

6. Whitespace

Pretty-printed indentation and newlines — great for humans, dead weight for machines.

7. Embedded raster images (the trap)

A base64 PNG hiding inside <image> can be 95% of the file size, and no SVG optimizer can shrink it. If your "SVG" is mostly an embedded bitmap, the honest fix is either re-exporting the artwork as true vectors or shipping an optimized WebP/JPEG instead.

How much can you actually save?

Illustrator exports: 50–80%
Sketch: 40–70%
Figma: 30–60%
Hand-written SVGs: 5–15%

And an optimized SVG is plain text, so gzip/Brotli squeezes another 50–70% on the wire. The two stack — do both.

Automate it

If the same SVGs ship in an app, make optimization a compile step, exactly like minifying JavaScript:

Vite: vite-plugin-svgo
Webpack: svgo-loader
Any CI: npx svgo -f src/icons -o dist/icons

Keep editable originals in the design repo, let the pipeline emit optimized files, and nobody has to remember anything again.

The full guide — with a browser-based optimizer (SVGO running client-side, no upload) and a batch processor for whole icon sets — is at svgeditor.dev.

Favicon not showing? Here's how to fix it (10 causes)

FF — Tue, 27 Oct 2026 03:37:08 +0000

A missing or broken favicon is one of the most common questions on Stack Overflow — and the answer is almost always one of ten things. Work through this checklist top to bottom and you'll find it.

1. Browser caching (the #1 cause)

Browsers cache favicons extremely aggressively — far more than regular pages. Even after you've fixed the issue, the old (broken) icon can persist for days. Test in this order:

Hard refresh: Ctrl/Cmd + Shift + R
Incognito / private window — if it shows there, it's just your cache
Visit the file directly: open https://yourdomain.com/favicon.ico. If you see the image, the file is fine and it's a cache/link issue.

2. Wrong file path

The href in your <link> must point to where the file actually is. A leading slash (/favicon.ico) means site root.

<!-- ❌ wrong if file is in /assets/ -->
<link rel="icon" href="favicon.ico">

<!-- ✅ absolute path from site root -->
<link rel="icon" href="/favicon.ico">

<!-- ✅ or the real location -->
<link rel="icon" href="/assets/favicon.ico">

3. Missing `<link>` tag

Some browsers fall back to /favicon.ico automatically, but you should never rely on that. Always declare icons explicitly in <head>:

<link rel="icon" type="image/x-icon" href="/favicon.ico" />
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png" />
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png" />

4. Wrong MIME type

If your server serves .ico as image/png (or vice versa) some browsers will refuse to render it. .ico should be image/x-icon or image/vnd.microsoft.icon; PNG should be image/png.

5. File not deployed

Check that the file actually made it to production. Open the file URL in a new tab. A 404 means it's not there — rebuild and redeploy, and confirm your build pipeline copies favicons into the output directory.

6. Non-square source image

Favicons must be square. If your source image isn't 1:1, browsers may show a stretched or blank icon. Crop first.

7. Framework-specific gotchas

Next.js App Router: icon files go in app/ (not public/) for auto-detection.
Next.js Pages Router: files go in public/, tags go in pages/_document.tsx.
Webpack / Vite: make sure favicon.ico is in your public/ or static/ directory and referenced in your HTML template.

8. HTTPS / mixed content

If your site is HTTPS but the favicon is referenced over HTTP, browsers will block it as mixed content. Always use HTTPS URLs or relative paths.

9. Service worker caching an old version

If you have a PWA with a service worker, it may be serving a cached HTML that references an old favicon. Update and re-register the service worker.

10. The SVG favicon isn't supported

SVG favicons aren't supported in every browser (notably older Chrome on Android). Always provide a PNG/ICO fallback alongside an SVG.

Still stuck? Automate the diagnosis

Paste your URL into the Favicon Checker and it will tell you exactly which icons and tags are missing or broken — no guessing.

Need a clean favicon package to replace a broken one? Generate one free at Favicon.one — text, emoji, SVG or image, every size and format, all processed locally in your browser.

Making legacy regexes readable — without changing what they match

FF — Mon, 26 Oct 2026 19:08:05 +0000

A pattern like this ships in real projects every day:

^(?\[(?:[A-Za-z0-9_.-]+)\])|^(?[A-Za-z_][A-Za-z0-9_]*)\s*=\s*(?"(?:[^"\\]|\\.)*"|'(?:[^'\\]|\\.)*'|[^#\n]*)\s*(?:#.*)?$

An INI-line parser: a section header or a key–value pair, three quoting modes for the value, trailing comments. Perfectly readable — to the person who wrote it, today. Come back in three months, or hand it to a teammate, and the review comment is always the same: what does this actually match?

Formatting solves this the way it's solved for every other language. The same pattern, laid out by structure:

^
(? \[(?:[A-Za-z0-9_.-]+)\])
|
^ (? [A-Za-z_][A-Za-z0-9_]*)
\s* = \s*
(? "
   (?: [^"\\] | \\ . )*
"
| ' (?: [^'\\] | \\ . )* '
| [^#\n]*
)
\s* (?:\#.*)?
$

Two branches instead of one buried |; three quote styles you can point at; a comment-stripping tail that's obviously a tail. Same language — the difference is purely typographic, which is exactly the point.

That's the Format panel in RegexTester.dev: open the toolbar's Format button or the deep link regextester.dev/format.

Three modes

Pretty — free-spacing layout with indented groups and stacked alternation branches.

Annotated — the pretty layout plus AST-derived inline comments naming each construct as it appears (alternation, negative lookahead, named capture, …).

Minify — the reverse direction: comments and free-spacing whitespace stripped back down to a single dense line for shipping.

Why the layout can't change behavior

Whitespace only becomes syntax when the x / extended flag is on, so the formatter emits its output with the x flag enabled for your dialect — PCRE2, Python, Java and .NET all spell it slightly differently, and the panel handles that. What it must never do is insert whitespace inside a character class (where it would be literal), inside a quantifier, or escape sequences that carry meaning. The layout rule is simple: only touch whitespace and comments outside classes and escapes.

Verified, not assumed

"Trust me, the layout is safe" is not a review argument, so the panel shows its work at the bottom of every run:

Round-trip proof — the formatter re-minifies its own output and compares it, byte for byte, with the escaped input. If the only difference is whitespace and comments outside classes — exactly what x mode ignores — you get a green Round-trip exact line.

Live behavior check — both forms (original, and formatted with x enabled) are executed against your current test string on the real engine for your flavor, and every match is compared: text, position, and each capture group's content. Only identical match lists earn the green Behavior verified line.

If either check fails, the line turns red and points you at the parse errors above. Formatting a regex you can't test is guesswork; here it's a proof.

Try it: open regextester.dev/format, paste your gnarliest pattern, and read it in one click — then let the round-trip proof tell you the formatter didn't change a thing.

Full write-up: regextester.dev/blog/regex-formatter. Free, no signup, everything runs locally in your browser.

One regex, seven engines: catch portability bugs before you ship

FF — Mon, 26 Oct 2026 18:46:32 +0000

"Regular expressions" is not one language. It's a family of dialects that look almost identical and disagree in exactly the places you don't look until production breaks:

\w is Unicode-aware by default in Python 3, PCRE2 and .NET — but ASCII-only in JavaScript.
Lookbehind must be fixed-width in PCRE2; .NET accepts variable width; RE2-based engines reject it entirely.
Possessive quantifiers, atomic groups, \K, named-group syntax (?<name>…) vs (?P<name>…) — every one of these is a line in some engine's grammar and an error (or a silent behavior change) in another's.

The standard workflow makes this invisible. You test the pattern in one tester with one flavor selected, it works, you paste it into another language — and the failure shows up far away from the regex: a log line that never matches, a validation that rejects valid input, an import script that silently skips rows.

A flavor selector doesn't solve this either — you'd still have to try every flavor by hand and compare results from memory. What you need is every engine answering at once, side by side, on the same input. That's what the Compat button in RegexTester.dev does.

Seven engine paths, one click

Type your pattern and a representative test string, then hit the Compat button in the toolbar — or open the deep link regextester.dev/compat directly.

One pattern runs through seven execution paths in parallel:

PCRE2 — real engine, compiled to WebAssembly
Go (regexp) — real engine, WebAssembly
Rust (regex) — real engine, WebAssembly
JavaScript — the browser's native RegExp
.NET — a real interpreter for System.Text.RegularExpressions syntax
Python — parser plus normalize-and-run path
Java — parser plus normalize-and-run path

Not simulated: the WASM paths are the actual engine builds, so a rejection or a match here is what the real engine does.

The three ways a port fails

Every engine reports one of three outcomes, and the panel clusters engines by their exact match sets:

Rejection — the pattern doesn't even compile. RE2's rejection of lookbehind, or a possessive quantifier a dialect has never heard of, is a build error you want to know about before the port.

Silent divergence — the worst one. The pattern compiles everywhere and simply disagrees. Classic example: \w+ against Unicode input gives JS and Java four matches where the other five engines give two, because \w is ASCII-only there. No error, no warning — different data.

Full agreement — all seven engines return identical match sets (text, position, groups), and the panel says so explicitly.

Exporting the verdict

The verdict copy is written to be pasted: one click copies a Markdown report listing every engine, its outcome, and the divergent match sets — drop it into a PR when you're porting a pattern between services written in different languages.

Try it: open regextester.dev/compat, paste the pattern you're about to port, and see all seven verdicts in a couple of seconds.

Full write-up: regextester.dev/blog/regex-compatibility-checker. Free, no signup, everything runs locally in your browser.

Buying the dip without catching the knife: a 2-line crypto pullback rule, walk-forward validated across 40 coins

FF — Sun, 25 Oct 2026 14:38:27 +0000

"Buy the dip" is the most repeated advice in crypto — and following it blindly is one of the most reliable ways to lose money. A 6% pullback inside a bull market and a 6% bleed on the way to zero print the same red candle. One is an opportunity; the other is a knife.

We built Trend Dip, a pullback strategy that only buys reclaims inside an uptrend, validated it walk-forward across 40 coins on 4-hour bars, and shipped it as a free preset in our in-browser backtester — no signup, the whole engine is WASM running locally in your browser, so you can re-run every number in this post on any coin in about a second.

The rule (two lines)

ENTRY:CROSS(C,LOWER) && C>TRENDMA    // buy the reclaim of the lower Bollinger band, in an uptrend
EXIT:CROSS(C,MID)                    // sell at the mid band

…where LOWER = MA(C,20) − 2·STD(C,20), MID = MA(C,20), and TRENDMA = MA(C,100). Each piece earns its place:

C > MA100 — the trend filter. This is what separates a dip from a knife. Below the 100-bar average, the same band reclaim is ignored entirely.
CROSS(C, LOWER) — buy the reclaim, not the touch. The entry fires on the bar whose close comes back above the band. The market has already rejected the low once before you spend a cent. This single change moved the OOS win rate by roughly ten points versus buying the first touch.
Exit at the mid band. The thesis is snap-back to the 20-bar mean, so that's where the trade ends. We tried smarter exits — trailing lows, trend-break exits — every one performed worse out of sample.
No stop in the formula. Deliberate: 4h crypto charts routinely flush 5% below the band and revert by the next close, and a stop converts those wicks into realized losses. Adding a 10–20% protective stop changed the results almost imperceptibly (stops almost never fired). The backtester still gives you an optional stop field if you want a hard tail cap.

How we validated it

Four rules, all of which matter:

Not one chart — forty. BTC, ETH, SOL, BNB, XRP, DOGE, AVAX, DOT and 32 more majors with long histories. A rule that only works on a cherry-picked chart is a screenshot, not an edge.
Walk-forward, not full-history. Each coin's ~500 days of 4h bars split 70/30: the first 70% is where parameters would effectively have been chosen; the final 30% is scored blind as one continuous out-of-sample segment. All headline numbers below are OOS only.
Realistic fills. Signals confirm at bar close, fill at the next bar's open — no lookahead — with 0.10% taker fee + 0.05% slippage per side (~0.3% round trip). The same engine and simulator that power the public backtest page ran every test.
Benchmarks. The identical harness scored the nine other strategies on the site on the same data.

The numbers

Out-of-sample metric (40 coins, 4h, 70/30)	Result
Win rate, all held-out trades	73.6% (174 trades)
Win rate, in-sample (for contrast)	62.9% (267 trades)
Coins profitable OOS	26 / 40
Coins beating buy & hold OOS	24 / 40
Coins winning ≥50% of held-out trades	33 / 35 with ≥3 trades
Median per-coin max drawdown	−6.1%
Worst / median / best held-out trade	−16.7% / +1.2% / +34.8%
Average holding time	12 bars ≈ 2 days
Win rate at 2× fees	69.5%
BTC / ETH / SOL win rate	83% / 75% / 100%

Two details deserve a second look. First, the OOS win rate is higher than the in-sample one — overfit strategies show the opposite signature: brilliant in the tuning window, collapsing the moment data is unfamiliar. Second, the edge survives fees at two to three times what a normal spot account pays.

Trying hard to break it

Six consecutive time slices scored separately: win rates 71%, 56%, 62%, 55%, 69%, 75% — every window above 50%. A regime-dependent fluke does not do that.
Parameter plateau. Defaults (20 bars, 2σ, MA100) sit in the middle of a plateau: 1.8σ–2.5σ all won 70–77%, neighbouring trend filters (50–200) all stayed positive. If performance collapses when you nudge a parameter 10%, you found noise.
Split-date sensitivity. Moving the walk-forward cut across 50/30 → 90/10 changed the aggregate win rate only between 55% and 66%.
Exit shoot-outs. Adding a 10-bar-low emergency exit or a trend-break exit lowered the OOS win rate (61.5% and 51.0%). The boring mid-band exit won — stops were selling into the very wicks the strategy profits from reverting.
Benchmarks: the best of the nine existing strategies managed a 51% OOS win rate on the same data.

Where it loses — read this part

73.6% win rate is not a money printer. The median winner is small (+1.2%) because the target — the mid band — is close. The profile is many small wins, occasional runners, occasional give-backs. The worst held-out trade lost 16.7%.
No formula stop means tail exposure exists. Historically the MA100 filter and mid-band exit capped the damage, but a coin that breaks down mid-trade holds until it recovers to the mid band. If that worries you, set the optional stop in the backtester and accept slightly worse expected numbers for a hard floor.
The held-out window is one market regime (~5 months per coin, dips inside an uptrend). In a full bear market the MA100 filter will simply keep the strategy flat for long stretches — designed behavior, not a bonus.
Survivorship bias is real — today's top-40 list excludes the coins that died.

Run it across the whole market

One coin's backtest is an anecdote. The scanner page runs the identical formula across a whole universe in one pass — each coin split walk-forward, ranked by out-of-sample Sharpe:

Under the hood (the dev part)

The whole thing — formula parser, indicator engine, backtest simulator, walk-forward scanner — is a Rust→WASM module evaluated entirely in your browser on real exchange candles. The strategy DSL is a tiny TDX-style language (ENTRY:CROSS(C,LOWER) && C>TRENDMA;), so every rule on the site is user-editable text, and the simulator fills at the next bar's open with configurable fees and slippage. Nothing you type is uploaded anywhere.

Re-run this exact strategy on any pair: backtest page
Scan the whole universe: scanner page
Full write-up with more stress tests: original article (canonical URL of this post — it's the same article, cross-posted)

Disclaimer: everything above is a historical backtest, not a promise. Backtested win rates decay in live trading. Not financial advice — crypto is volatile and you can lose your entire investment.

Testing automata-theory exercises in the browser: a regex flavor for CS coursework

FF — Sun, 04 Oct 2026 12:19:22 +0000

If you've ever taught or taken a formal languages course, you know the workflow: the exercise says write a regular expression for all strings over {a,b} containing an even number of a's, you write (b|ab)* on paper... and then you have no way to check it.

Programming regex flavors can't validate it for you — they're full of conveniences the formal dialect doesn't have: character classes, quantifier shorthands, anchors. What you want is a checker that speaks the textbook dialect: union ∪ or |, concatenation, Kleene star *, plus +, parentheses. Nothing more.

RegexTester.dev now ships a Formal Automata Theory flavor exactly for this.

What it accepts

Symbols from your chosen alphabet (typically a, b, or 0, 1)
Union: ∪ or |
Concatenation: juxtaposition or .
Kleene star: *, and one-or-more: +
Grouping with parentheses

Everything else — \d, [a-z], lookahead, backreferences — is rejected with an explanation, because the point is to exercise exactly the constructs the course covers.

Instant feedback

Type the expression and test strings in, and you immediately see which strings match and which don't — so you can iterate on the exercise instead of waiting for a grader.

The flavor runs on the same engine infrastructure as the other eight dialects (PCRE2, RE2, .NET, Python, Java, Go, Rust, JavaScript), so the matching behavior is well-defined and consistent.

Why a browser tool for coursework?

Because the feedback loop is everything when learning. The gap between writing (b|ab)* on paper and knowing whether it's right is where most of the confusion in a formal languages course lives. Close that gap to seconds and students experiment their way to understanding: they can see that (b|ab)* matches babb but not abab, and fix their mental model immediately.

It also works the other direction: instructors can build exercise sets with permalinks — every regex and test string combination in the tester has a shareable URL, so "check your answer against this" becomes a link.

Try it: open regextester.dev, pick the Formal Automata flavor from the selector, and test that even-number-of-a's exercise.

Full write-up: regextester.dev/blog/Formal-automata-theory-flavor. Free, no signup — built for students and educators.