DEV Community: Katia Belokon

One Space Broke the JSON-LD Headline on 62 Pages

Katia Belokon — Mon, 09 Nov 2026 06:59:15 +0000

One of my page headings, Your IP, plainly, showed up in the JSON-LD as "Your IP , plainly". The same bug was in the structured data of 62 pages. On screen, every one of them looked right.

The site is MyIPScan, which I built. This post is about the bug class, how it happens, and a test that catches it.

TL;DR

If you derive a JSON-LD headline from heading HTML, inline tags like  can leave a space before punctuation: Your IP, plainly → Your IP , plainly.
Fix: delete inline tags without replacing them, and turn only block boundaries into spaces.
Catch it at build time: the JSON-LD headline must equal the visible heading's normalized text, and no generated text field may match / [,.;:!?)]/.

Why one space matters

JSON-LD is a copy of your page written for machines, and no human reads it. Google recommends JSON-LD for structured data when your setup allows it (Search Central intro), and its guidelines say: "Your structured data must be a true representation of the page content" (General Structured Data Guidelines).

The headline was still true, just sloppy. But a template stamps the same mistake onto every page it builds, and nothing on screen tells you. The visible heading was correct on all 62 pages.

Checking the page in a browser is real QA. For this bug it checked the wrong output.

Two explanations that don't fit

The source text. If the space were in the CMS, the visible heading would show it too. It didn't. A bug in the source shows up in both copies.

JSON escaping. JSON.stringify escapes quotes, backslashes and control characters. It does not add spaces.

That leaves the step that turns heading HTML into a string. I can't show you my original generator, but the output has the fingerprint of one specific mistake.

How this class of bug happens

The code below is an illustration of the bug class, not my generator. It reproduces the exact output, which is enough to reason about it.

A common way to strip HTML tags in JavaScript replaces every tag with a space, so that onetwo doesn't become onetwo. Then it squeezes whitespace:

// Illustration: a naive stripper that turns every tag into a space
function naiveStrip(html) {
  return html.replace(/<[^>]*>/g, ' ').replace(/\s+/g, ' ').trim();
}

naiveStrip('Your <em>IP</em>, plainly');
// "Your IP , plainly"

naiveStrip('What is my <em>IP address</em>?');
// "What is my IP address ?"

Step by step:

Your IP, plainly
Tags → spaces: Your IP , plainly (two spaces after "Your", one before the comma)
Collapse whitespace: Your IP , plainly

The collapse hides half the damage. The double space after "Your" merges into one, so the result looks almost right. The space before the comma has nothing to merge with, so it stays.

The rule the stripper breaks: inline elements do not create word boundaries; block elements do.  sits inside a run of text. , <li>, <h2> and   end one.

textContent and innerText

In a DOM, textContent "returns the concatenation of the textContent of every child node" (MDN), so  is harmless. It also includes <script> and <style> content, and it ignores  : in Chromium, Line one line two gives "Line oneline two". innerText handles  , but for an element that isn't rendered, such as one in a detached tree, it returns the same as textContent (MDN). In a static build step with no browser, that is the case you are in.

The fix, as an illustration

For a heading, which is short and mostly inline, a small explicit function is enough. It deletes 26 inline tags and turns everything else into a space:

const INLINE = /<\/?(a|abbr|b|bdi|bdo|cite|code|data|dfn|em|i|kbd|mark|q|s|samp|small|span|strong|sub|sup|time|u|var|wbr)\b[^>]*>/gi;

function headingText(html) {
  return html
    .replace(INLINE, '')          // inline tags: no boundary
    .replace(/<br\s*\/?>/gi, ' ') // line break: boundary
    .replace(/<[^>]*>/g, ' ')     // any other tag: boundary
    .replace(/&nbsp;/g, ' ')
    .replace(/\s+/g, ' ')
    .trim();
}

headingText('Your <em>IP</em>, plainly');        // "Your IP, plainly"
headingText('What is my <em>IP address</em>?');  // "What is my IP address?"
headingText('Line one<br>line two');             // "Line one line two"

The comments are real output from Node 22. This version decodes only  . If your headings contain & or ’, decode them properly (the test below shows a minimal decoder). If your build already has an HTML parser, use it instead of regex. The point is the boundary rule.

One design choice helps more than the function: build the visible heading and the JSON-LD headline from the same string, not from two code paths. Then they can't drift.

A Node test for the JSON-LD headline

The function fixes one build. A test keeps the next refactor from bringing the bug back. This one reads the built HTML, so it checks what a crawler fetches, not the template:

// jsonld.test.mjs  (run: node --test jsonld.test.mjs)
import { test } from 'node:test';
import assert from 'node:assert/strict';
import { readFileSync, readdirSync } from 'node:fs';
import { join } from 'node:path';

const INLINE = /<\/?(a|abbr|b|bdi|bdo|cite|code|data|dfn|em|i|kbd|mark|q|s|samp|small|span|strong|sub|sup|time|u|var|wbr)\b[^>]*>/gi;
const ENT = { amp: '&', lt: '<', gt: '>', quot: '"', apos: "'", nbsp: ' ' };
const decode = (s) => s.replace(/&(#x[0-9a-f]+|#\d+|\w+);/gi, (m, e) =>
  e[0] !== '#' ? (ENT[e.toLowerCase()] ?? m)
  : String.fromCodePoint(e[1].toLowerCase() === 'x' ? parseInt(e.slice(2), 16) : +e.slice(1)));
const text = (html) => decode(html.replace(INLINE, '').replace(/<[^>]*>/g, ' '))
  .replace(/\s+/g, ' ').trim();

function* pages(dir) {
  for (const e of readdirSync(dir, { withFileTypes: true })) {
    const p = join(dir, e.name);
    if (e.isDirectory()) yield* pages(p);
    else if (e.name.endsWith('.html')) yield p;
  }
}

// every JSON-LD block, any attribute order
const blocks = (html) => [...html.matchAll(
  /<script\b[^>]*type=["']application\/ld\+json["'][^>]*>([\s\S]*?)<\/script>/gi
)].map((m) => JSON.parse(m[1]));

// walk objects, arrays and @graph; yield [key, string] for the fields we check
const FIELDS = new Set(['headline', 'name', 'description']);
function* fields(node) {
  if (Array.isArray(node)) for (const n of node) yield* fields(n);
  else if (node && typeof node === 'object') {
    for (const [k, v] of Object.entries(node)) {
      if (FIELDS.has(k) && typeof v === 'string') yield [k, v];
      else yield* fields(v);
    }
  }
}

const SPACE_BEFORE_PUNCT = / [,.;:!?)]/;

for (const file of pages(process.env.DIST ?? 'dist')) {
  test(file, () => {
    const html = readFileSync(file, 'utf8');
    const found = [...fields(blocks(html))];
    for (const [key, value] of found) {
      assert.doesNotMatch(value, SPACE_BEFORE_PUNCT, `${key}: ${JSON.stringify(value)}`);
    }
    const h1 = html.match(/<h1\b[^>]*>([\s\S]*?)<\/h1>/i);
    const headline = found.find(([k]) => k === 'headline');
    if (h1 && headline) assert.equal(headline[1], text(h1[1]));
  });
}

I ran it against four small fixture pages: a correct article, the broken headline, a page with &, ' and an @graph, and a FAQPage with no heading and a bad question name. Excerpt of the spec reporter output (node --test --test-reporter=spec, Node 22):

✖ dist/bad/index.html (2.665891ms)
✔ dist/entity/index.html (1.36117ms)
✖ dist/faq/index.html (1.048332ms)
✔ dist/good/index.html (0.35228ms)
...
  AssertionError [ERR_ASSERTION]: headline: "Your IP , plainly"
...
  AssertionError [ERR_ASSERTION]: name: "Can someone see my <em>IP</em> ?"

The two assertions catch different things:

Equality catches any drift between the visible heading and the headline, whatever the cause. The entity fixture passes because text() decodes & and ' before comparing.
The punctuation regex runs on every headline, name and description in every block, including @graph and nested FAQ questions. That covers pages with no heading to compare against.

The regex has false positives. I checked these in Node and all three match: Learn .NET in a weekend, Wait ... what, and French spacing like Bonjour !. Add exceptions if your copy has them.

Checking it by hand

Two free tools show you the parsed JSON-LD for a URL or a pasted snippet:

Google's Rich Results Test
The Schema Markup Validator

A stray space is valid Text, so there is nothing for them to flag. They show you the string, and you have to read it. That's why the automated test matters more than the manual check.

The rule

I built MyIPScan, a network privacy toolkit, and this bug sat in its structured data on 62 pages while every page looked fine.

Test the copy you don't look at. Visual QA only checks the page humans see.

My SSL expiry checker was six weeks off on github.com

Katia Belokon — Mon, 02 Nov 2026 09:14:14 +0000

TL;DR: My SSL certificate expiry check said github.com was covered until 11 Jan 2027. The ECDSA certificate github.com was actually serving expires on 29 Nov 2026, about six weeks earlier, and it also serves an RSA certificate that expires on 30 Dec 2026. My tool reads Certificate Transparency logs, and the logic picked the newest certificate in the log, one that was issued but not being served. A CT-based check should report the range of currently valid certificates and alarm on the earliest date, not the newest.

My SSL checker said github.com had a certificate valid until 11 Jan 2027. The certificate github.com was handing out expires on 29 Nov 2026.

Same hostname, about six weeks apart. One of those dates was wrong, and it was mine.

An SSL certificate expiry check that reports more time than you have fails quietly. You find out when the certificate does.

Where my dates come from

I built MyIPScan, a set of browser-based network and privacy tools. The SSL checker does not open a TLS connection to your server. Direct TLS inspection is not available in the runtime it runs in, so it reads public Certificate Transparency data instead: crt.sh first, Cert Spotter as a fallback.

CT logs are a public record of TLS certificates "as they are issued or observed" (RFC 6962, formally obsoleted by RFC 9162, which keeps the same wording). A CA may even submit a precertificate before the final certificate is issued (RFC 6962, Section 3.1). That is useful for auditing CAs. It says nothing about which certificate a server presents today.

I knew that. The logic still picked the newest certificate for the hostname and called it the answer.

Two explanations that don't fit

Stale CT data. CT can lag behind a fresh deployment, and the checker's own page says so. But lag would make the tool report an older certificate than the server's. Here the tool was ahead of the server: the log already held a certificate valid to 11 Jan 2027 that github.com was not serving.

One certificate, read wrong. If there were a single live certificate, there would be a single date to get wrong. There were two live ones.

The cause: two served certificates and a third in the log

These are the three certificates in the case:

Certificate	Valid to	Days left (as of 22 Oct 2026)
ECDSA, served	2026-11-29	38
RSA, served	2026-12-30	69
Newest in CT logs, not served	2027-01-11	81

Serving two certificates is a normal setup. A server keeps an RSA and an ECDSA certificate and picks one per connection. nginx, for example, lets ssl_certificate be specified multiple times "to load certificates of different types, for example, RSA and ECDSA" since version 1.11.0 (nginx docs). I am not claiming GitHub runs nginx; it is just the clearest documentation of the mechanism.

In TLS 1.3 the client sends a signature_algorithms extension (RFC 8446, Section 4.2.3), and the server chooses a certificate that fits it. Browsers offer both RSA and ECDSA, so which one you get is the server's preference. A client that only offers RSA signatures gets the RSA certificate.

The two served certificates were issued at different times, so they expire a month apart. A renewal was already in the logs. My tool skipped both served certificates and reported the one nobody was receiving.

How to check this yourself

You can ask for one key type at a time. These are the commands to run; I am not pasting output, because the dates will have moved by the time you read this:

# Offer only ECDSA signatures: expect the ECDSA certificate
openssl s_client -connect github.com:443 -servername github.com \
  -tls1_3 -sigalgs "ecdsa_secp256r1_sha256:ecdsa_secp384r1_sha384" </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate -issuer

# Offer only RSA-PSS signatures: expect the RSA certificate
openssl s_client -connect github.com:443 -servername github.com \
  -tls1_3 -sigalgs "rsa_pss_rsae_sha256:rsa_pss_rsae_sha384" </dev/null 2>/dev/null \
  | openssl x509 -noout -enddate -issuer

-sigalgs sets the list the client sends, and "the server selects one entry in the list based on its preferences" (openssl s_client docs). If the server holds two certificates, the two commands should print two different notAfter lines for one hostname.

Then compare them with the currently valid entries for the same name on crt.sh. It is common to find more valid certificates in the log than the server is using.

What an SSL certificate expiry check should report

There is no single expiry date for a hostname. There is a set of currently valid certificates, and the server serves some subset of them. Without a handshake you cannot know which subset.

So a CT-based check should do three things:

Report a range. Take every certificate for the exact hostname that is valid now and show the earliest and latest not_after. For github.com on 22 Oct 2026 that is 29 Nov 2026 to 11 Jan 2027, not a confident 11 Jan.
Alarm on the earliest date. A newer certificate in the log only proves a renewal was issued, not that it was deployed. Until something confirms deployment, the earliest date is the one that can break you. The latest date goes next to it as "renewal logged".
Count each certificate once. A precertificate and its final certificate are separate log entries with the same issuer and serial number.

A sketch of that logic:

const DAY = 86400000;

function expiryReport(certs, host, now = Date.now()) {
  const valid = certs.filter(c =>
    c.names.includes(host) &&               // exact match: *.github.com is not github.com
    Date.parse(c.not_before) <= now &&
    Date.parse(c.not_after) > now
  );

  // precertificate + final certificate = one certificate
  const unique = [...new Map(
    valid.map(c => [`${c.issuer}|${c.serial}`, c])
  ).values()];
  if (unique.length === 0) return { status: "none" };

  const days = unique
    .map(c => Math.floor((Date.parse(c.not_after) - now) / DAY))
    .sort((a, b) => a - b);
  const earliest = days[0];
  const latest = days[days.length - 1];

  return {
    earliest,                               // headline date
    latest,                                 // shown as "renewal logged"
    renewalLogged: latest > earliest,
    count: unique.length,
    status: earliest <= 14 ? "alarm" : "ok",
  };
}

This trades some false alarms for no silent misses. An old certificate that was replaced early but has not expired will keep the earliest date low. That is annoying, and it is the right direction to be wrong in. If you can open a TLS connection, use the handshake result to drop certificates the server no longer serves.

The range has a limit too. If the server serves a currently valid, logged certificate for this exact name, its date is inside the range. A misconfigured server serving something else is outside what CT can tell you.

What I changed

The checker's page now says it plainly: the records describe certificates that were logged, "not necessarily the one the server is serving right now", and nothing is read from a live handshake. It also tells you to re-check a few days after a renewal. The range view described above is the approach I am working toward; it is not on the page yet.

A range is less satisfying than one number. It is also not wrong.

The rule to take away

A certificate log tells you what was issued. Only a handshake tells you what is served. If your SSL certificate expiry check reads CT data, report the range across all valid certificates and alarm on the earliest one. If you can open a TLS connection, do it once per key type, because one hostname can have two expiry dates at the same time.

If you want to see what CT logs know about your own domain, the checker is on MyIPScan.

How to detect a CDN when your scanner runs on Cloudflare (the Server header won't tell you)

Katia Belokon — Fri, 30 Oct 2026 05:42:05 +0000

My CDN detector said Cloudflare. Then Cloudflare. Then Cloudflare. Three sites, three identical answers, and the reason was not the sites: the detector trusted the Server header, and it was reading that header from inside Cloudflare.

TL;DR

The scanner runs on Cloudflare. From there, every site it fetched came back with server: cloudflare, so it reported Cloudflare on 3 sites out of 3.
curl from an ordinary machine shows something else: github.com answers Server: github.com, BBC answers Server: BBC-GTM.
Server is not a CDN field. To detect a CDN, use DNS (NS and CNAME) plus headers the CDN documents as its own, and count those headers only when you are not fetching from inside that CDN.

Three for three

I built MyIPScan, a site with free network and privacy checks. One of them takes a domain and reports what it can see from the outside: HTTPS, redirects, security headers, DNS, and a line called "CDN".

The scanner found Cloudflare on three sites out of three.

Cloudflare is big. Three out of three should still make you suspect the detector before the sites.

Why a wrong CDN label matters

People use that label to answer practical questions. Who terminates my TLS? Whose IP ranges do I allow in the firewall? Who do I contact about a block page? Is my origin hidden?

If the tool says "Cloudflare" for everyone, every one of those answers is wrong. A detector that never says "no" is worse than no detector.

The usual suspects, and why they don't fit

The first things you'd suspect are the boring ones: the scan followed a redirect to some third-party host that really is on Cloudflare, or the code parsed the header wrong (case, merged values, a default leaking in).

Neither explains a result that is identical for unrelated sites. The value was the plain string cloudflare, the same every time. That pattern points at the place the request was made from, not at the sites.

The Cloudflare server header, seen from two places

So ask the same question from a machine that is not on Cloudflare. Plain curl, only the line that matters:

$ curl -sI https://github.com | grep -i '^server'
Server: github.com

$ curl -sI https://www.bbc.com | grep -i '^server'
Server: BBC-GTM

Same header name, different answers. From the scanner, both said cloudflare. From outside, neither did.

The scanner runs on Cloudflare, the same platform that serves the rest of the site. I have not found a Cloudflare document that describes what the Server header looks like on responses fetched from there, so I won't guess at the mechanism. The observed part is enough: from inside Cloudflare, server: cloudflare appeared on responses from sites whose Server header, fetched from outside, says something else.

BBC: a CDN that Server never mentions

BBC shows the other half of the problem. A public urlscan.io scan of a www.bbc.com page from 17 July 2026 shows the main response with server: BBC-GTM and via: 1.1 BBC-GTM, 1.1 Belfrage, 1.1 varnish, served from an IP in AS54113, which urlscan labels Fastly.

So that response came through Fastly, and Server did not say Fastly. That is not the header misbehaving. Server names server software, and it never promised to name a CDN. It just can't be used to detect one, in either direction.

How to detect a CDN reliably

A CDN has to be wired into a domain somewhere public. There are two such places: DNS, and the headers the CDN documents as its own.

NS records. Cloudflare's docs say standard nameservers "follow the pattern <proper_name>.ns.cloudflare.com", and advanced nameservers are hosted on foundationdns.com, foundationdns.net and foundationdns.org. If a zone's NS records point there, Cloudflare runs that zone's DNS.

CNAME records. A hostname put behind a CDN often has a CNAME to the CDN. Fastly's docs list targets such as <something>.customer.fastly.net, <something>.map.fastly.net and dualstack.e.sni.global.fastly.net.

CDN-owned headers. Cloudflare says it adds Cf-Ray and Cf-Cache-Status to the response sent to the visitor. Fastly documents X-Served-By, "set by Fastly by default on all responses that we process", in the format cache-{datacenter}{nodeid}-{datacenter}.

None of these is perfect alone. A Cloudflare zone can proxy only some hostnames. An apex served by A records has no CNAME. Headers can be stripped. And a CDN-owned header read from inside that same CDN has the same weakness as Server: it may describe your own path, not the site.

That gives the rule I adopted after this bug: detect a CDN by DNS (NS, CNAME) and the CDN's own headers, never by Server.

A sketch in code

This is an illustration, not the production code, and I have not run it against live DNS. It uses Cloudflare's DNS-over-HTTPS JSON API and returns evidence rather than a verdict:

const NS_RULES = [
  { cdn: 'Cloudflare', re: /\.ns\.cloudflare\.com\.?$/i },
  { cdn: 'Cloudflare', re: /\.foundationdns\.(com|net|org)\.?$/i },
];

const CNAME_RULES = [
  { cdn: 'Fastly', re: /\.fastly\.net\.?$/i },
];

const HEADER_RULES = [
  { cdn: 'Cloudflare', test: h => h.has('cf-ray') },
  { cdn: 'Fastly', test: h => /^cache-/i.test(h.get('x-served-by') || '') },
];

async function doh(name, type) {
  const r = await fetch(
    `https://cloudflare-dns.com/dns-query?name=${encodeURIComponent(name)}&type=${type}`,
    { headers: { accept: 'application/dns-json' } }
  );
  const j = await r.json();
  return (j.Answer || []).map(a => a.data);
}

// Naive: right for www.bbc.com -> bbc.com, wrong for www.example.co.uk
// (it returns co.uk). Use a Public Suffix List library in real code.
function apexOf(host) {
  return host.split('.').slice(-2).join('.');
}

// vantage: the CDN your scanner itself runs on, e.g. 'Cloudflare', or null.
export async function detectCdn(host, headers, vantage = null) {
  const evidence = [];

  for (const ns of await doh(apexOf(host), 'NS'))
    for (const r of NS_RULES)
      if (r.re.test(ns)) evidence.push({ cdn: r.cdn, via: `NS ${ns}` });

  for (const c of await doh(host, 'CNAME'))
    for (const r of CNAME_RULES)
      if (r.re.test(c)) evidence.push({ cdn: r.cdn, via: `CNAME ${c}` });

  for (const r of HEADER_RULES) {
    if (r.cdn === vantage) continue; // our own CDN's headers prove nothing here
    if (r.test(headers)) evidence.push({ cdn: r.cdn, via: 'CDN header' });
  }

  // Deliberately no rule for the Server header.
  return evidence;
}

Two details matter more than the regexes.

First, there is no rule for server. It can go into a report as raw data, but it never produces a CDN label.

Second, the vantage check. If the scanner runs on Cloudflare, a cf-ray on a fetched response is skipped, and a Cloudflare label has to come from DNS. NS answers do not have this problem: a zone's nameservers are the same whoever asks. (CNAME and A answers can vary by resolver location, so treat them as evidence, not proof.)

How to check a detector like this

Use the same comparison that exposed the bug: run the detector, then run curl -sI and dig NS / dig CNAME from a machine outside the CDN your scanner lives on. Every label should be backed by something you can reproduce from there. If the only support is a header, and your scanner sits on that CDN, the label should not exist.

The rule

Before you trust what a response says about where it came from, ask where you are standing when you read it. A header describes the path, and your own infrastructure is part of the path. DNS describes the domain.

The CDN and origin hints in the Website Exposure Scanner on MyIPScan are best-effort signals, not proof, and the page says so. (I built MyIPScan.)

Has your monitoring ever reported something that turned out to be a fact about the machine it ran on? What gave it away?

Sources: Cloudflare HTTP headers, Cloudflare nameservers, Fastly X-Served-By, Fastly: routing traffic, urlscan.io scan of a www.bbc.com page.

Two invisible bytes wiped 130 CSS colour tokens on 462 pages, and every check passed

Katia Belokon — Tue, 27 Oct 2026 09:42:19 +0000

TL;DR

My stylesheet started with two UTF-8 byte order marks instead of one. The decoding algorithm browsers use strips only the first, so the second became part of the first selector, and the :root rule holding 130 colour tokens stopped matching on 462 pages.
All checks and the deploy passed. Only a live measurement of the rendered page caught it: background #ffffff where it should have been #f5f0e8.
Check for a BOM after byte 0 in CI, and assert computed styles on the live page, not just files.

The background that came back white

I built MyIPScan, a set of free network-privacy checks served as a static site. The first rule in its stylesheet is a :root block with 130 colour tokens as CSS custom properties.

After a deploy, a live measurement of the page background came back #ffffff. It should have been #f5f0e8, a warm off-white.

Nothing else flagged it. Every check passed, the deploy went through, and the 130 tokens were undefined on all 462 pages that load that stylesheet.

Why nothing went red

If your design system lives in custom properties, your whole visual identity hangs off one selector. When that selector stops matching, nothing throws. No parse error, no failed step, no console warning. The pages still load, and they just look wrong.

Two suspects that don't fit

A stale cached stylesheet is the obvious first suspect. It explains a page that looks old, not one that has lost every token at once.

A cascade problem, some later rule overriding the tokens, is the second. One line in the console separates the two:

getComputedStyle(document.documentElement).getPropertyValue("--bg");

An overridden property still has a value. An empty string means the property was never declared for that element, so the cascade is not the problem. If the declarations are in the file and still don't apply, look at the selector.

The cause, in six bytes

$ head -c 6 styles.css | od -An -tx1
 ef bb bf ef bb bf

EF BB BF is the UTF-8 encoding of U+FEFF, the byte order mark. This file has two.

One is harmless. CSS Syntax Level 3 decodes a stylesheet with the Encoding Standard's decode algorithm, which sniffs for a BOM, reads three bytes and discards them. It does that once. There is no loop.

The second EF BB BF goes through the UTF-8 decoder as an ordinary character, U+FEFF, and reaches the tokenizer. CSS Syntax lists U+FDF0 to U+FFFD among its non-ASCII ident code points, so U+FEFF can start an identifier. The first rule stops being this:

:root { --bg: #f5f0e8; /* ...129 more */ }

and becomes this:

\FEFF:root { --bg: #f5f0e8; /* ...129 more */ }

That is a type selector for an element whose name is U+FEFF, combined with :root. In an HTML page the root is <html>, so the rule matches nothing. It still parses and still shows up in the CSSOM.

You might expect the browser to drop the rule as invalid. In a minimal repro I built for this article (headless Chromium, stylesheet served over local HTTP), it was still there, with the extra character in front:

JSON.stringify(document.styleSheets[0].cssRules[0].selectorText);
// ":root" with an invisible U+FEFF in front of it

From there, var() does what MDN describes for an undeclared property: use the fallback if there is one, otherwise resolve to an invalid value, and the property is treated as unset. In the repro, background: var(--bg, #fff) gave rgb(255, 255, 255), and background: var(--bg) gave rgba(0, 0, 0, 0), transparent over a white canvas. Either way, it looks white. With a single BOM, the same file gave rgb(245, 240, 232).

How a file gets two

The usual ways a file ends up with a second BOM:

concatenating files that each start with a BOM, when the first piece is empty apart from its BOM;
an editor or tool prepending a BOM to a file that already has one;
a build step that writes its own BOM in front of content that already carries one.

Don't count on your linter. In the repro, stylelint 17.16.0 with selector-type-no-unknown exited 0 on the double-BOM file, while the same rule rejected foo:root as an unknown type selector.

Your search tool can hide it too. ripgrep sniffs for a BOM by default and strips a leading one before searching (checked with ripgrep 14.1.0), so a search for the bytes misses a single BOM at the start of a file. rg -E none searches raw bytes. GNU grep works if you force the C locale; under a UTF-8 locale the same pattern found nothing in my test with grep 3.11:

LC_ALL=C grep -rlP '\xEF\xBB\xBF\xEF\xBB\xBF' --include='*.css' dist/

The fix and how to confirm it

The fix is deleting the second three bytes. The confirmation is the same live measurement, read in the format the browser gives you. getComputedStyle(document.body).backgroundColor returns rgb(), not hex, so the expected value is rgb(245, 240, 232): 0xf5 = 245, 0xf0 = 240, 0xe8 = 232. The broken value, #ffffff, is rgb(255, 255, 255). Compare a hex string with an rgb() string and your check fails for the wrong reason.

Two checks are worth adding. These are illustrations, not production code.

A byte check for CI, which allows a BOM at offset 0 and fails on any after it:

// check-bom.mjs
// run: find dist -name '*.css' -exec node check-bom.mjs {} +
import { readFileSync } from "node:fs";

const BOM = Buffer.from([0xef, 0xbb, 0xbf]);
let bad = 0;

for (const file of process.argv.slice(2)) {
  const buf = readFileSync(file);
  let at = buf.indexOf(BOM, 1); // offset 0 is allowed
  while (at !== -1) {
    console.error(`${file}: stray BOM at byte ${at}`);
    bad++;
    at = buf.indexOf(BOM, at + 1);
  }
}
process.exit(bad ? 1 : 0);

Use find rather than dist/**/*.css: without globstar, bash expands ** like * and skips files directly in dist/.

And a rendered check, which catches this bug and every other way a token can vanish:

// after deploy, in a headless browser (Playwright shown)
await page.goto(LIVE_URL);
const bg = await page.evaluate(() =>
  getComputedStyle(document.body).backgroundColor
);
if (bg !== "rgb(245, 240, 232)") throw new Error(`background is ${bg}`);

The byte check knows one bug. The rendered check doesn't care why the colour is wrong, which is the point. Pick one token you'd notice, assert its exact computed value, and run it against the live URL.

The rule I'm keeping

A green pipeline checks the files you shipped. Only a rendered page tells you what the browser did with them. A linter reads your CSS as text. The browser reads it as bytes, through an algorithm that removes exactly one BOM and treats a second as part of your selector.

Has a stylesheet ever passed every check you had and still rendered wrong for you? I'd like to know what finally caught it.

VPN Kill Switch Test From a Browser Tab: What Polling Can and Can't Prove

Katia Belokon — Mon, 26 Oct 2026 08:16:27 +0000

TL;DR

A browser can't see the firewall rules behind a VPN kill switch. It only sees answers: which address a server saw, or no reply at all.
Sampling leaves gaps, and a leak shorter than the gap between two samples can vanish completely.
No reply is not a pass. It only proves nothing came back.

You click Quit in the VPN app, and the tab that was supposed to record the leak is now behind it. That is the basic problem with any VPN kill switch test run from a web page: to test the kill switch you have to break the tunnel on purpose, and breaking it takes you away from the tab doing the measuring.

That detail shaped the VPN kill switch test on MyIPScan. I built MyIPScan, and this post covers how a browser-based recorder works and what it cannot tell you.

What a kill switch actually is (and why a browser can't see it)

A kill switch lives below the browser. Mullvad's open-source app is a good reference because its security document spells it out. The app integrates with the system firewall: "This means WFP on Windows, PF on macOS and nftables on Linux." When it cannot build a tunnel, it enters an error state that "locks the firewall so no traffic can flow (except the always active exceptions)."

The same document separates two things people often merge. The app's "kill switch" is "the fact that the connecting, disconnecting and error states prevent leaks via firewall rules." The "Lockdown mode" setting, which the document says is "regularly misunderstood as the kill switch," only decides whether the disconnected state blocks traffic too.

None of this is visible from JavaScript. A page can only send requests and record what happened to them.

How the VPN kill switch test records a drop

The test runs in three steps, and the first two exist to give the recorder something to compare against:

Capture your own network. Disconnect the VPN completely and record the address your ISP gives you.
Capture the tunnel. Connect again and record the VPN's exit address.
Force the drop. Start recording, then break the tunnel the way it breaks in real life: quit the VPN app or disable the network adapter. Run it on a desktop: a phone's background tab will likely stop sampling.

Each reading is one request to the site's own /api/ip-sample endpoint, which, in the page's words, "sees the address the request arrives from and sends it back with its AS number, provider name and country." The loop asks for a sample every 1.5 seconds, and every 0.6 seconds for twelve samples after anything changes, so transitions get finer resolution than the quiet stretches.

Every sample lands in one of four buckets:

Outcome	Meaning	Counted as exposure?
No reply	Nothing came back	No
Tunnel address	Matches step 2	No
Your own address	Matches step 1	Yes
Some other address	Matches neither	No, timed separately

Only "your own address" counts as a leak. A different VPN server after a reconnect is not your ISP, so it gets its own timer.

Below is my illustration of how such a loop can be written, not the site's code:

const samples = [];

async function takeSample() {
  const t = performance.now();
  try {
    const res = await fetch('/api/ip-sample', {
      cache: 'no-store',                 // never answer from cache
      signal: AbortSignal.timeout(3000), // a hung request is a result too
    });
    const { ip } = await res.json();
    samples.push({ t, ip, hidden: document.hidden });
  } catch {
    samples.push({ t, ip: null, hidden: document.hidden }); // "no reply"
  }
}

A recorder should request with cache: 'no-store', which makes the browser fetch "from the remote server without first looking in the cache" (MDN, RequestInit); a cached answer could show the tunnel address after the tunnel is gone. It should also note document.hidden per sample, to explain later why the gaps grew.

Why the gap you ask for is not the gap you get

The loop asks for 1.5 seconds, or 0.6 seconds in fast mode. The browser decides what you actually get.

According to MDN's setTimeout page, "Firefox Desktop has a minimum timeout of 1 second for inactive tabs," and Firefox for Android has a minimum of 15 minutes for inactive tabs "and may unload them entirely." Chrome throttles hidden-tab timers too, and the MyIPScan page sums up the desktop case as browsers clamping "background timers to about one per second."

Chrome also has intensive throttling, introduced in Chrome 88, where timers are checked once per minute. MDN lists its conditions: nesting count of 5 or higher, the page invisible for more than 5 minutes, silent for more than 30 seconds, and WebRTC inactive. It only applies after 5 minutes hidden, so it is not relevant to a seconds-long test.

Put the one-second clamp next to step 3. Forcing a drop means switching to the VPN app, so the measuring tab is hidden at the moment you care about. The 0.6-second fast mode gets clamped to about 1 second while the tab is hidden, and slow requests stretch the spacing further. Each request's round-trip time also adds to the timing uncertainty.

So the page says the recorder reports "the gap it achieved rather than the gap it wanted, and says how long the tab was hidden." If the achieved gap was, say, 2.0 seconds, then any statement about leaks shorter than that is off the table.

Turning samples into a window with two bounds

For a run of consecutive "your own address" readings, there are two defensible numbers:

Lower bound: the page defines it as "the span actually observed, from the first matching sample to the last." The leak lasted at least this long.
Upper bound: the widest window the neighbouring samples still allow. The leak could have started just after the previous sample and ended just before the next one.

Again, my illustration, not the site's code:

function exposureBounds(samples, i, j) { // i..j = matching run
  const lower = samples[j].t - samples[i].t;
  const before = samples[i - 1]?.t ?? samples[i].t;
  const after  = samples[j + 1]?.t ?? samples[j].t;
  return { lower, upper: after - before };
}

The page's own example output is "at least 3.6s, at most 4.8s". With 0.6-second fast-mode sampling on both sides of the run, 3.6 + 2 × 0.6 = 4.8, which is consistent with the page's example. A single number like "4.2 seconds" would look more precise and be less true.

What polling can't prove

Silence is not success. A "no reply" sample fits a working kill switch, but also Wi-Fi reassociating, DNS failing, or a timeout. The page puts it as: "Samples that get no reply show that traffic was not moving, not who stopped it."

Short leaks fall between samples. If the achieved gap is 1.5 seconds, a 400 ms window of unprotected traffic can sit entirely between two requests and never appear. The page says it directly: "A window shorter than that gap can be missed entirely." Zero matches means "none observed at this resolution", not "none occurred".

It sees HTTP from one tab, not the whole machine. Background apps, an OS update service, a torrent client, DNS through another resolver: any of that can leak without touching the tab's requests.

It errs toward under-reporting. If your own address changed after you captured it (the page names "a reconnected router, a mobile handover, carrier-grade NAT"), "a genuine exposure can land in the 'some other address' column instead." The error stays in the conservative direction.

One run is one run. The page: "It is one session, one device, one browser and one moment," and "It is not a test of any VPN application." Nobody should publish "Brand X has no kill switch" from a single recording.

On privacy, every sample is a request, so the server sees your address each time it answers. The page states that "Readings are not logged or stored on the server," that the recording "stays in this tab until you close it," and that to name the provider "only the AS number is looked up (RIPEstat), never your address." It also offers a switch to show full addresses instead of masked ones.

Where this leaves a browser-based test

Polling from a tab is a decent smoke test: it can catch a leak that lasts seconds and time it with error bars. It cannot certify a kill switch. For that, capture packets at the interface (Wireshark or tcpdump on the physical adapter while you kill the VPN), because that is where the firewall rules act.

If you build anything like this, keep one rule: report the resolution you achieved next to every result, and never let a missing answer count as a passing one.

My regex found an IP address in the word "candidate"

Katia Belokon — Thu, 22 Oct 2026 13:57:09 +0000

TL;DR: Versions 1.0.0 and 1.0.1 of my npm package @myipscan/leak-check reported strings like e:2703186080 as IP addresses. A hex character class matched the last letter of candidate: plus the ICE foundation, and my Node test never reached the parser. 1.0.2 reads the address field (from candidate.address, or by position), validates it and skips mDNS names. If you pull IPs out of ICE candidate strings with a regex, check yours.

Two addresses that weren't

On 17 August 2026 my WebRTC leak detector told me my browser was exposing two IP addresses:

{ "supported": true, "ips": ["e:2703186080", "e:1510270939"] }

Neither is an address. By then the package had shipped twice, the second time with a passing test, and the e turned out to be the last letter of the word candidate.

The package is @myipscan/leak-check. I wrote it for MyIPScan, my set of free browser privacy checks. It asks the browser which addresses it will hand to a page script, and its only network traffic is a STUN request, to Google's server by default.

What bothered me most was how well the output survived a glance: a hex digit, a colon, a run of numbers. Squint and it could be the tail of an IPv6 address.

A detector that throws costs me a visitor. One that returns a confident wrong value costs the visitor. They compare it with their VPN's exit address and decide either that something leaked or that leak tests are noise, and either way they act on a fact my code made up. For a privacy tool the order is fixed: the right answer, then an honest "couldn't check", then anything else. 1.0.0 and 1.0.1 delivered the third.

How my test went green

My test ran the detector in Node. On 1.0.0 it failed with ReferenceError: window is not defined, because the code touched window inside the Promise.

1.0.1 went out 91 minutes later with a guard at the top of the Promise:

if (typeof window === "undefined") return resolve({ supported: false, ips: [] });

The test went green because that line is where it ended. I had made it pass by making it test less.

The same release moved the regex into a variable, var IP. I edited the line holding the bug, gave the bug a name and published it again.

The e in candidate

var IP = /([0-9]{1,3}(\.[0-9]{1,3}){3}|[a-f0-9:]{10,})/i;

// a server-reflexive candidate; 203.0.113.7 is a documentation address
var line =
  "candidate:1510270939 1 udp 1677729535 203.0.113.7 54322 typ srflx raddr 0.0.0.0 rport 0";

var m = IP.exec(line);
console.log(m[1], m.index); // "e:1510270939" 8

JavaScript returns the leftmost match, and at each position it tries both alternatives before moving one character right. The IPv4 branch only wins if nothing matched earlier in the string.

The second branch wants ten or more characters from [a-f0-9:], case-insensitive. Here is where it finds them:

candidate:1510270939 1 udp 1677729535 203.0.113.7 54322 typ srflx ...
ca d da e:1510270939
        ^ 8: first run of 10+ characters from [a-f0-9:]
                                      ^ 38: the address

The runs are ca, d, da, then e:1510270939, twelve characters. The match starts at 8 and the address is never considered.

The IPv6 branch described which characters an address may contain, not what an address looks like. A candidate line is full of long hex-looking runs.

On host and server-reflexive lines the old regex lands on the foundation or, when the foundation is short, on the ten-digit priority. Add a TURN server and relay candidates carry priorities short enough that it sometimes reaches the real address, which is how a bug like this survives a spot check. The foundation isn't even always a number: RFC 8839 allows letters in it too.

Read the field the grammar names

The candidate attribute is defined in RFC 8839, section 5.1: "candidate" ":" foundation SP component-id SP transport SP priority SP connection-address SP port SP cand-type .... The address is the fifth space-separated field. (My source comment still cites RFC 5245, which RFC 8839 replaced.)

The core of 1.0.2, condensed:

// candidate:<foundation> <component-id> <transport> <priority> <address> <port> typ <type> ...
function addressOf(c) {
  if (c.address) return c.address;              // newer browsers parse it for you
  const fields = String(c.candidate || "").split(" ");
  return fields.length > 4 ? fields[4] : "";     // fifth field, by position
}

function isIp(s) {
  const v4 = /^(\d{1,3})\.(\d{1,3})\.(\d{1,3})\.(\d{1,3})$/.exec(s);
  if (v4) return v4.slice(1).every((n) => Number(n) <= 255);
  if (!s.includes(":")) return false;
  const halves = s.split("::");                  // at most one "::"
  const groups = s.split(":").filter(Boolean);
  if (halves.length > 2 || groups.length > 8) return false;
  if (halves.length === 1 && groups.length !== 8) return false;
  return groups.every((g) => /^[0-9a-f]{1,4}$/i.test(g));
}

pc.onicecandidate = (e) => {
  if (!e.candidate) return finish();             // null candidate: gathering is over
  const addr = addressOf(e.candidate);
  if (/\.local$/i.test(addr)) return;            // mDNS name: the browser withheld the IP
  if (isIp(addr)) ips.add(addr);
};

The test I should have written feeds the detector the two candidates a typical browser produces, an mDNS host candidate and a server-reflexive one:

const test = require("node:test");
const assert = require("node:assert");
const { detectWebRTCLeak } = require("@myipscan/leak-check");

function fakePC(lines) {
  return function () {
    this.createDataChannel = () => {};
    this.close = () => {};
    this.createOffer = async () => ({});
    this.setLocalDescription = async () => {
      setTimeout(() => {
        lines.forEach((candidate) => this.onicecandidate({ candidate: { candidate } }));
        this.onicecandidate({ candidate: null });
      });
    };
  };
}

test("returns the address from a server-reflexive candidate", async (t) => {
  t.after(() => { delete global.window; });
  global.window = { RTCPeerConnection: fakePC([
    "candidate:2703186080 1 udp 2122260223 9b36a1c4-5e2f-4d1a-8c3b-0f7e6d5c4b3a.local 54321 typ host",
    "candidate:1510270939 1 udp 1677729535 203.0.113.7 54322 typ srflx raddr 0.0.0.0 rport 0",
  ]) };
  const { ips } = await detectWebRTCLeak();
  assert.deepStrictEqual(ips, ["203.0.113.7"]);
});

On 1.0.1 it returns ["e:2703186080", "e:1510270939"], exactly the output I saw in the browser. On 1.0.2 it returns ["203.0.113.7"] and passes.

RTCIceCandidate.address saves the split where it exists, but MDN lists it as Baseline only since 2024, so the fallback stays. isIp checks shape only: it lets a trailing colon through and rejects the valid ::ffff:192.0.2.1. If you need strict IPv6 in a browser, new URL("http://[" + s + "]") throws on malformed input. What the new code can no longer do is return a piece of another field.

The broken versions were the latest release for about two hours, 17:56 to 20:04 UTC on 17 August. Both are still on the registry, so use ^1.0.2. 1.0.3 only added repository and issue links. The source is on GitHub.

Three results, not two

supported: false: the check could not run (no window, no RTCPeerConnection, or the constructor threw). It never means "no leak".
supported: true with addresses: what the browser was willing to give a page script. A public address here is expected. It is a leak only if it differs from the address your HTTP requests come from, for example your ISP's address while a VPN is on.
supported: true, ips: []: no address came back. With a reachable STUN server you would normally see at least your public address, so an empty list usually means STUN was blocked or slower than the 2-second timeout. In 1.0.2 it is also what a failed offer returns. On its own it proves nothing. (Private addresses hidden behind mDNS names ending in .local are skipped in every case.)

The trap downstream is if (!ips.length) showClean(). That turns "I couldn't look" into "nothing there".

Rules I'm keeping

Test the path that touches the browser. A fake RTCPeerConnection that replays recorded candidate lines is a few lines of code, and it fails on 1.0.1.
Parse by the grammar, then validate. If the spec says field five, read field five, then check its shape.
Never let "could not check" render as "clean". Carry the third state all the way to the UI.
Read every line before you publish it. 1.0.0's index.js was 19 lines, and I published it without reading all of them. npm pack --dry-run shows what will ship. Reading it is still on me.

Rule 3 is the one I haven't finished. 1.0.2 still folds a STUN timeout or a failed offer into supported: true with an empty list, which is exactly the collapse rule 3 warns about. The fix is an explicit "incomplete" state, and it isn't in the package yet. If you've shipped a check with a third state, how did you get it to the UI without someone turning it back into a boolean?

If you want to see what your own browser hands out, MyIPScan's WebRTC leak test runs the same gathering in the page and sorts candidates into public, private and mDNS-masked. (I build MyIPScan. The package is MIT licensed.)