Word blocklist vs AI moderation — what to filter user content with

There's a town in England called Scunthorpe. For years its residents couldn't register on various services: an English swear word hides inside the town's name, and filters dutifully cut the whole thing. Nearby Penistone caught the same treatment, along with everyone else unlucky with their letters.

That's the portrait of a word blocklist: it doesn't know where a word ends, and it certainly doesn't know what you meant. It is, however, free and instant.

So let's work out when that's enough, and when you need a classifier.

How each one works

A word blocklist is your own file of strings. A message arrives, you search it for matches. Found one, reject it. No network calls, no training, complete predictability.

AI moderation is a call to a classifier model. It reads the whole message and returns scores per harm category: harassment, hate, violence, self-harm and so on. It doesn't hunt for words — it judges meaning.

Compared on six criteria

Cost. A blocklist is free, full stop. AI moderation varies: OpenAI's moderation endpoint is free, while dedicated moderation vendors charge by volume. Call it a tie, with the blocklist ahead only where you want no external dependency at all.

Evasion. This one's a rout. A blocklist is bypassed in seconds: spaces between letters, a digit for a letter, a Latin "a" for a Cyrillic one, an emoji in the middle. You add a variant, the user invents the next, forever. A classifier reads the meaning of the sentence and survives those tricks.

Understanding context. A blocklist can't tell a threat from a quotation, an insult from a medical term, or someone swearing at themselves from someone swearing at another user. A classifier can — imperfectly, but by design. That's the core difference: one searches for strings, the other judges an utterance.

Languages. You maintain a blocklist by hand, per language, including transliteration and slang. Classifiers cover dozens of languages out of the box, and the multimodal versions have improved most on non-English ones.

Speed and offline. Here the blocklist wins outright. It's an in-memory check: sub-millisecond, no network, nothing to bill, nothing to break when a provider has an outage.

False positives. Both err, but differently. A blocklist errs stupidly and predictably (Scunthorpe); a classifier errs cleverly and unexpectedly (sarcasm read as a threat). The classifier, though, gives you a number, so you can move the threshold; a blocklist is always binary. How to pick that threshold is in the piece on false positives.

Where a blocklist genuinely wins

It isn't obsolete — it just has a different job. A blocklist is irreplaceable when you need an exact list of specific strings:

• domains and referral links you won't allow in comments;
• phone numbers and messenger handles, if you run a marketplace and deals must stay on-platform;
• competitor names, promo codes, names of your internal services;
• spam templates you've already caught — the ones that arrive by the hundred, identical.

A classifier is useless for that: it has no idea what you consider unwanted in your product. Universal harm categories say nothing about domains and promo codes.

Who should use what

No hedging:

• Building your first app with comments, reviews or chat. Take AI moderation. The free endpoint covers the main harm categories in an hour's work — the wiring is in the moderation guide. Your own word list will take months to maintain and still lose.
• You need your own platform rules (no contact details, no outside links). Take a blocklist — but for specific strings, not for profanity.
• You need both — which is most real products. Order matters: blocklist first (instant, free, kills the known stuff), classifier second (judges everything else). Keep the blocklist short, ten lines or so: a long list is a false-positive farm.
• You can't call the network (offline app, closed network, data rules). Then it's a blocklist plus a local classifier model — the cloud option simply isn't available to you.

And the thing neither option solves: a filter is no substitute for a report button and a human who reads the queue. Automation catches the obvious; people report what it missed. Both are guardrails around your product, not one magic check.

Can't I just use regular expressions?

A regex is the same blocklist, only more flexible: you can tell it "a letter, then any separator, then a letter" and catch spacing tricks. It kills off some primitive evasion and stays instant. But it can't handle meaning by definition, and a complex profanity regex starts catching innocent users very fast — and it's harder to debug than a plain list.

What about profanity in languages with heavy inflection?

Don't try to close that with a list — you'll lose. Languages like Russian offer too many forms: prefixes, suffixes, cases, transliteration, letter swaps. A classifier understands such words in context better than any list of roots. And if you specifically need a strict tone (a kids' app, say), check your model's output as well as the user's input, and deliberately keep the threshold low, accepting the extra false positives.