DEV Community: Peter

One invisible character broke skin tones for 12 emoji, and I shipped it

Peter — Fri, 21 Aug 2026 07:33:59 +0000

👍 supports five skin tones. My emoji API said it supported none.

The data was right. Both upstream sources were right. The bug was one line of lookup code and a character you cannot see.

The symptom

I had just published an emoji API and was checking endpoints by hand:

curl https://eeemoji.com/api/v1/emojis/thumbs-up

{
  "emoji": "👍",
  "name": "thumbs up",
  "skinToneSupport": false,
  "skinToneVariants": null
}

That is plainly wrong. Thumbs up has had skin tone variants since Emoji 1.0.

The tempting move here is to patch the response. Hard-code a list of hand emoji, set the flag, move on. I nearly did. Instead I went looking for why, and the why turned out to affect 152 records, not the ten or so I had spotted.

Two sources, both correct

My data bundle is generated from two packages:

emojibase-data for names, keywords, shortcodes and skin tone variants
unicode-emoji-json for the skin_tone_support flag

First thought: they disagree, and I picked the wrong one. So I checked:

thumbs up      emojibase skins=5    unicode-emoji-json skin_tone_support=True
thumbs down    emojibase skins=5    unicode-emoji-json skin_tone_support=True
raised hand    emojibase skins=5    unicode-emoji-json skin_tone_support=True
raised fist    emojibase skins=5    unicode-emoji-json skin_tone_support=True

Both sources say yes. Neither is wrong. My generator was producing false from two inputs that both said true, which is the sort of result that means you are looking at the wrong layer.

The actual bug

Here is the line:

const skinSupport = unicodeEmojiData[eb.emoji]?.skin_tone_support ?? false;

eb.emoji is emojibase's emoji character. unicodeEmojiData is keyed by emoji character. This looks like it cannot fail.

It fails for 152 of 1,949 emoji, because the two packages disagree about something invisible:

// emojibase's `emoji` field for thumbs up
[...eb.emoji].map(c => c.codePointAt(0).toString(16))
// => ['1f44d', 'fe0f']     <-- includes U+FE0F

// unicode-emoji-json's key for the same emoji
// => '1f44d'               <-- no U+FE0F

U+FE0F is the variation selector. It is a zero-width character that tells the renderer "draw this as colour emoji, not monochrome text". It has no visual form of its own. Both strings print as 👍 and look identical in every editor, diff and terminal I use.

So the lookup missed. And then:

?? false

swallowed the miss and returned a confident, wrong answer. No exception, no warning, no undefined creeping into the output. Just false, in 152 records, shipped to production and served over a public API.

Why the fallback is the real villain

The FE0F mismatch is a fact of life. Emoji data packages disagree about variation selectors constantly, and both are defensible: emojibase gives you the fully-qualified sequence, unicode-emoji-json gives you the base.

The thing that turned a mismatch into a bug is ?? false.

?? on a lookup you expect to succeed converts "I could not find this" into "the answer is no". Those are completely different statements, and the second one is unfalsifiable from the output. If the code had thrown, or produced undefined, or logged once, I would have caught it in minutes.

// what I wrote
const skinSupport = lookup[key]?.skin_tone_support ?? false;

// what would have caught it
const entry = lookup[key] ?? lookup[stripVariationSelectors(key)];
if (!entry) throw new Error(`No entry for ${key} (${toCodePoints(key)})`);
const skinSupport = entry.skin_tone_support;

The rule I took from this: a ?? default on a lookup that should always hit is a silent-failure generator. Use it for genuinely optional data. For a required join, fail loudly.

Fixing it against the actual authority

Rather than patch the generator and re-run it, I reconciled the whole bundle against Unicode's own emoji-test.txt, which lists every fully-qualified sequence including toned ones. If the file contains 1F44D 1F3FB, thumbs up supports skin tones. That is the authority, not a package's interpretation of it.

The script derives both the flag and the variant list, so it can be re-run when Unicode ships a new version:

curl -o emoji-test.txt https://unicode.org/Public/emoji/latest/emoji-test.txt
EMOJI_TEST_FILE=emoji-test.txt node scripts/fix-skin-tone-data.js --check

Result: 26 records corrected, 311 to 330 with skin tone support. Thumbs up and down, raised hand, raised fist, the four pointing hands, ear, snowboarder, surfer, swimmer, wrestlers, bunny ears, ballet dancer.

Three bugs in the fix itself

I wrote --check mode before --write mode, which is the only reason this section exists rather than a story about corrupting 1,900 records.

1. Stripping every FE0F. My first attempt removed all variation selectors before looking up the toned sequence. But the toned form of 👱‍♀️ is:

1F471 1F3FB 200D 2640 FE0F
      ^tone            ^this one survives

Only the selector attached to the base is replaced by the modifier. Later ones belong to other parts of the sequence. Stripping all of them made 128 emoji look like they had lost skin tone support. Caught because 👱‍♀️ obviously has tones, so the rule had to be wrong.

2. Multi-person emoji tone every figure. 🧑‍🤝‍🧑 is not person + tone + handshake + person. It is:

1F9D1 tone 200D 1F91D 200D 1F9D1 tone

Both people. My bundle had stored only the first figure toned, which renders as a toned person beside an untoned one. The flag was right and the variants were wrong, so the fix now checks those independently.

3. The fix for #2 matched everything. My "tone every person code point" function returns the sequence unchanged when there are no person code points. An unchanged sequence is of course present in the file, so every emoji "passed" and the script proposed 1,376 gains including 😀 grinning face. Fixed by requiring that a modifier was actually inserted.

Each of those passed typecheck and lint. None would have been caught by anything except running the thing and reading the output.

What I would tell past me

When output contradicts every input, the bug is in the join, not the data. I spent time diffing two sources that agreed with each other.
?? false on a required lookup is a lie generator. It answers a question you did not ask.
Invisible characters need a code point view. console.log(emoji) shows you nothing. [...s].map(c => c.codePointAt(0).toString(16)) shows you the bug.
Write --check before --write. My data-fix script had three bugs. Dry run caught all three.

The API this came out of is at eeemoji.com/api. Free, no key, and the skin tone flags are now reconciled against Unicode 17.0. If you are pulling emoji data from more than one package, it is worth checking how many of your joins are quietly falling through to a default.

The barcode prefix does not tell you where a product was made

Peter — Thu, 20 Aug 2026 16:52:54 +0000

There is a claim about barcodes that circulates every few years, usually attached to a call to boycott something: the first digits tell you which country a product was made in. Scan a jar, read the prefix, learn the origin.

It is wrong, and the organisation that issues the numbers says so directly:

Since GS1 user companies can manufacture products anywhere in the world, GS1
Prefixes do not identify the country of origin for a given product.

What the prefix actually identifies is the GS1 member organisation that allocated the number to the brand owner. A company registers with one organisation, usually the one where it has its seat, and keeps those number ranges wherever it later manufactures. A Swedish company with a 73x prefix can have every unit made in Vietnam and the barcode will not change.

I went looking for a dataset that got this right and did not find one, so I built it. It sits behind a Swedish-language lookup tool where you can paste a barcode and see the same answer without installing anything.

What annoyed me enough to build something

Most lookup services label the field country of origin. Not issuing organisation, not country of the issuing organisation. The label itself teaches the myth to everyone who uses the tool.

The npm package with the most obvious name is gs1-prefix-code-to-country-code. Last published in 2023, no TypeScript types, no keywords, and the entire API is named after the wrong idea. Install it and the mistake propagates into your codebase as a function name.

That felt like a small thing worth fixing properly.

Two sources, and what happens when they disagree

The table is reconciled against GS1's own prefix list and the English Wikipedia article List of GS1 country codes. Most entries agree. Two do not:

612 appears in Wikipedia as Somalia, but is absent from GS1's own list
894 is listed as Bangladesh by Wikipedia, while GS1 says the range is managed centrally

The obvious move is to pick one and move on. I kept both disagreements in the record instead, as a boolean field:

import { GS1_RANGES } from "gs1-prefix";

GS1_RANGES.filter((r) => r.sourceDisagreement);
// the two ranges where the sources conflict

This is the part I actually care about. A dataset that silently resolves conflicts looks cleaner and tells you less. If you are building something where an unallocated prefix matters, you want to know that one of your 144 ranges rests on a single source.

Using it

npm install gs1-prefix

import { lookup } from "gs1-prefix";

const result = lookup("7310865004703");

result.prefix;                        // "731"
result.range.issuingOrganisation;     // "GS1 Sweden"
result.range.organisationCountry;     // "Sweden"
result.range.organisationCountryCode; // "SE"
result.checkDigitValid;               // true

Python, same data, same names in snake_case:

pip install gs1-prefix

from gs1_prefix import lookup

result = lookup("7310865004703")
result.range.issuing_organisation   # "GS1 Sweden"

Or skip the dependency and take the CSV, JSON or DCAT-AP file from gs1-prefix-ranges.vercel.app. CORS is open, so you can fetch it straight from a page.

The detail that trips people up

A 12-digit UPC-A is a GTIN-13 with an implied leading zero. Read the twelve digits as they are and you land on the wrong prefix, and the answer still looks plausible, which is the worst kind of bug.

lookup("012345678905").paddedFromUpc; // true
lookup("012345678905").prefix;        // "001", not "012"

The flag is there so you can tell the two cases apart rather than wondering.

The check digit follows the same principle. It returns true, false, or null when the length carries no check digit, so "there is no check digit here" and "the check digit is wrong" are different answers.

Ranges that are not countries at all

Worth knowing before you write range.organisationCountry into a UI:

Range	What it is
`020`-`029`, `200`-`299`	Restricted distribution, defined locally
`040`-`049`	Restricted to within one company
`977`	Periodicals, ISSN
`978`-`979`	Books, ISBN. `979-0` is sheet music, ISMN
`980`	Refund receipts
`981`-`983`, `990`-`999`	Coupons

Those carry issuingOrganisation: null and a note explaining what the range is for. Around 281 of the 1000 possible prefixes are unallocated, and the lookup returns a null range rather than guessing.

One caution if you maintain your own copy

Several GS1 member organisations publish stale versions of the list. GS1 Slovakia's still names Serbia and Montenegro, a country that stopped existing in

A stale list looks exactly like a current one, so check the date on whatever you copy from.

That applies to this dataset too. It is generated from a table I maintain, and the generation date is in the JSON.

Licence and where it lives

MIT for the code, CC BY 4.0 for the data. Attribution goes to smartatest.se, where the table is maintained.

Site and raw files: gs1-prefix-ranges.vercel.app
Repo: github.com/xoocode/gs1-prefix-ranges
npm and PyPI: gs1-prefix

Corrections to the data are welcome as an issue. If you find a range where GS1 and Wikipedia disagree and I have not flagged it, that is the most useful thing you could tell me.