DEV Community: Tomer N

Why Roblox Turns Your Messages Into ###, and What a Game’s Chat Filter Should Do Instead

Tomer N — Tue, 03 Nov 2026 14:00:00 +0000

Picture a player typing a quick warning to a friend: there's a monster right behind you. They throw in a swear word, because it's urgent. Their friend sees ###########.

That's not my example. It's Roblox's own, from a post its safety team published in March 2026 about why it's moving away from hash marks. And it's the best summary I've seen of what goes wrong when a game filters chat badly: the rule gets enforced, and the conversation dies. (Drafted with AI, sources checked by hand.)

If you've played or built a game with chat, you've probably run into these. What does ### mean in Roblox? Why can't I say Discord? Why did Kahoot rename me? So I went through what Roblox and Kahoot actually say their filters do, case by case, and what each one teaches you if you're building chat for your own game.

What ### means

Roblox's help center answers it in one line: when you see hashtags in place of words, the word or phrase "was blocked by our filters."

The filter isn't one list. In the March post, Roblox describes three parts:

Rules, which can block new terms within minutes when something happens in the real world.
Small specialized models, trained to catch the words Roblox doesn't allow. Roblox says these are good at that task but "can't reason very well," so they miss language that changes fast.
Large models, added this year. When the small ones aren't sure, the text goes to a bigger model that can weigh more context.

Roblox says the combination catches more leetspeak (letters swapped for numbers or symbols) and cut missed attempts to share personal information, like phone numbers and social handles, by 20 times.

Screenshot: Roblox's Experience Chat help article

Where it goes wrong, case by case

1. The whole line disappears

The monster example is the problem in one picture. The filter found something it didn't allow, and the reader lost the entire message, including the part that mattered for the game.

Roblox's fix, since March, is to rephrase instead of hash, starting with profanity. Its example: "Hurry tf up!" becomes "Hurry up!" Everyone in the chat is told the message was rephrased, and the swearing still counts against the sender. More serious messages still go through the rest of its safety system.

Roblox's monster example as it hid it, then masked and rephrased by me

You don't need a language model to do better than hiding the whole line. Masking only the words that broke a rule keeps the warning readable. Rephrasing is nicer, but it's a bigger build, and Roblox itself says it "won't always rephrase things perfectly."

2. Nobody says why

A row of hash marks doesn't tell the sender which word was the problem, or whether they're in trouble. Roblox's answer was real-time warnings, added in May 2025, that tell players when they've broken a rule. In its experiments, warnings and time-outs cut filtered messages by 5% and consequences from abuse reports by 6%.

That's the cheapest fix on this list. If your filter blocks something, tell the sender what kind of thing it was.

3. "Discord" isn't a swear word

This one confuses players the most. Roblox's filter isn't only about language. Its Community Standards say you may not share links to outside sites except through the Social Links feature on a game, group or profile page, which needs an age check and an age of at least 16. Any other effort "to direct users off of Roblox" is prohibited. Its safety page says filtered chat blocks personal information "and instructions on how to move off the platform."

So "add me on Discord" isn't blocked because Discord is rude. It's blocked because it's directions off the platform, which the rules forbid.

The lesson for your game: decide what you're filtering for, and write it down. Swearing, slurs, threats, personal information and off-platform contact are different rules, and players accept them better when they can tell them apart.

4. The list catches innocent words

Kahoot's nickname filter is a classic word list. Kahoot keeps a list of words it deems universally inappropriate, checks every nickname against it, and changes a match to something neutral. Its help page even warns teachers that a group of players joining with names like "router" may be the filter at work.

To its credit, Kahoot gives teachers a way back: they can ask support to allow a wrongly filtered nickname, or add a missed one to the deny list. It also offers a nickname generator in Classic mode, where players spin for a friendly two-word name like "kind tiger" instead of typing one.

That's the honest trade-off. A list will always block some innocent names, so you need a path to fix it, and for young players, picking from safe names beats filtering typed ones.

5. Everyone gets the same filter

A ten-year-old and an adult shouldn't see the same chat. Roblox's safety page says players 12 and younger also have personal information filtered out, and that in restricted games marked for strong language, users 18 and older may be allowed to swear, as long as it isn't used to harass, threaten or discriminate.

If your players span ages, make the strictness a setting, per server or per player.

6. Banter isn't abuse

This is the hardest one. In a game, "nice try loser" is usually a taunt, and "I know where you live" never is. A word list can't tell them apart, because the difference isn't in the words. It's in whether the line is about the game or about a person.

Full disclosure, I build Unprofane, and this is the problem its gaming context was made for: in its docs, gg ez, uninstall and nice try loser are allowed there, while kys noob and I know where you live are blocked.

If you're building on Roblox

Roblox filters its own chat for you, but not everything else. Its creator docs say you're responsible for filtering any text you display that you don't control, like signs players write on, pet names saved in data stores, words your game generates at random, or content fetched from an outside server. If Roblox finds a game that doesn't filter, it removes the game until you add filtering.

The call is TextService:FilterStringAsync, run on the server with the text and the UserId of whoever wrote it:

local TextService = game:GetService("TextService")

local function filterForEveryone(text, fromUserId)
    local ok, result = pcall(function()
        return TextService:FilterStringAsync(text, fromUserId)
    end)
    if not ok then
        return nil -- show nothing when the filter fails
    end
    local ok2, filtered = pcall(function()
        return result:GetNonChatStringForBroadcastAsync()
    end)
    return ok2 and filtered or nil
end

Use GetNonChatStringForBroadcastAsync for text everyone sees and GetNonChatStringForUserAsync for text shown to one player, which filters for that player's age. And the docs ask you not to filter on every keystroke: filter once the player submits.

If you're building your own

Here's the short version of everything above:

Mask the word, not the line. Keep the rest of the message readable.
Tell the sender why. A category is enough: swearing, personal info, a link.
Keep the rules separate. Language, threats and off-platform contact are different checks with different answers.
Give players a way back. A report button for wrong blocks, and an allow list you actually update.
Set strictness by age. Stricter for kids, looser for adults in adult spaces.
Decide what happens when the check fails. Show nothing, like Roblox's sample does, or hold the message for a moment. Don't let a timeout quietly turn the filter off.
Offer safe choices for the youngest players. Kahoot's nickname generator is a good model.

None of this needs a big team. Most of it is a decision you write down before launch instead of after the first angry thread.

Have fun building, and may your players never see ########### again :)

I work on Unprofane, a profanity and abuse filter for user text, including game chat.

How to Move Off Perspective API in Python Before December 31

Tomer N — Thu, 29 Oct 2026 13:00:00 +0000

Somewhere in a lot of Python codebases there's a call to discovery.build("commentanalyzer", "v1alpha1", ...). It scores comments for toxicity, it's worked for years, and after December 31, 2026 Google's Perspective API won't answer it anymore.

Google's notice says the service stays up until that date, there's no extension, and they won't offer migration help. So I'm going to walk through the move myself, in the order I'd do it, with the code. (Written with AI help; facts checked.)

By the end you'll have the same Python client making the same calls, pointed at a Perspective-compatible API, with a separate key for staging and production, a threshold you picked on your own data and a one-line way back.

Full disclosure, I built Unprofane, the API this guide switches to. I'll also say where something else is the better pick.

1. Find every place that calls Perspective

Before changing anything, list the calls. A plain search over your Python files usually turns them all up:

grep -rn --include="*.py" -e "commentanalyzer" -e "comments()" .

Look for three things in what it prints: the discovery.build call, every comments().analyze(...) and comments().suggestscore(...), and any batch built with new_batch_http_request(). Also note which attributes you request. That matters in step 6.

2. Get a key for each environment

Make two keys in Unprofane's dashboard: a test key that starts with up_test_ for staging and a live key that starts with up_live_ for production.

The test key is free and answers 100 checks a month across the account, with no card. A live key needs a paid plan, and the smallest is $9 a month for 25,000 checks.

Keep your Google key. Until December 31 it's your rollback.

3. Change the build call

The Google client doesn't hardcode Google's host. It builds itself from a discovery document, and Unprofane serves one that names its own host. So the change is one argument, discoveryServiceUrl:

import os
from googleapiclient import discovery

client = discovery.build(
    "commentanalyzer",
    "v1alpha1",
    developerKey=os.environ["UNPROFANE_KEY"],  # up_test_YOUR_KEY on staging, up_live_YOUR_KEY in production
    discoveryServiceUrl="https://api.unprofane.com/$discovery/rest?version=v1alpha1",
    static_discovery=False,
)

response = client.comments().analyze(body={
    "comment": {"text": "you are a clown"},
    "requestedAttributes": {"TOXICITY": {}},
    "languages": ["en"],
    "doNotStore": True,
}).execute()

print(response["attributeScores"]["TOXICITY"]["summaryScore"]["value"])

Reading the key from an environment variable means staging and production run the same code and differ only in the value. static_discovery=False makes the client fetch the discovery document from the URL you pass, instead of looking for a copy bundled inside the library.

Everything after build stays as it is. The path, the request body and the ?key= parameter are Google's.

4. What it returns

The response has Perspective's shape: attributeScores with a summaryScore and spanScores for each attribute, then languages and detectedLanguages. Asking for TOXICITY and INSULT looks like this (the numbers show the shape, not a score to expect):

{
  "attributeScores": {
    "TOXICITY": {
      "spanScores": [{ "begin": 0, "end": 15, "score": { "value": 0.71, "type": "PROBABILITY" } }],
      "summaryScore": { "value": 0.71, "type": "PROBABILITY" }
    },
    "INSULT": { "summaryScore": { "value": 0.78, "type": "PROBABILITY" }, "spanScores": [] }
  },
  "languages": ["en"],
  "detectedLanguages": ["en"]
}

Errors come back the way Google sent them too: an HttpError with Google's status and Google's wording. So the except blocks you already wrote keep working.

5. Run it on staging

Point staging at the test key and run the tests you already have for your moderation code: a clean comment, a nasty one, an empty one, a very long one, and a bad key. The refusals come back as the same HttpError shapes, so if your tests asserted on Google's error messages, they should still pass. If one fails, the next section is usually why.

6. Check what doesn't carry over

Here's the part to read before you ship, not after.

Seven production attributes are scored: TOXICITY, SEVERE_TOXICITY, IDENTITY_ATTACK, INSULT, PROFANITY, THREAT and SEXUALLY_EXPLICIT.
The New York Times attributes aren't. If your code asks for SPAM, LIKELY_TO_REJECT, INFLAMMATORY or the others, you get the same error Google gave for an attribute it didn't know. Remove them, or set dropUnsupportedAttributes to leave them out quietly.
Google's account errors have no match. A key restricted to a referrer or an IP address, "API not enabled", billing: none of that exists here. A key is valid or it isn't.
Batches have limits Google didn't have. A batch answers at most 100 parts, 30,000 characters of comments together and 256 KiB. Past that it's refused whole with INVALID_ARGUMENT, so split big batches. Each part counts as one check.
suggestscore still answers {}. The moderator score you send is stored as a correction on your account, and it doesn't change any score.

And one difference runs the other way, which is easy to miss. Some comments Google refused now get a score:

comments in languages Google detected but didn't score, like Hebrew and Turkish,
SEXUALLY_EXPLICIT outside English (Google scored it in English only),
HTML comments, which are scored without their tags.

If your code caught Google's error for an unsupported language and published the comment anyway, those comments now go through your threshold like everything else. That's probably what you wanted all along, but your moderation queue may grow on day one, so tell your moderators.

7. Pick a new threshold

This is the step that actually takes time, and the one I'd never skip.

A threshold belongs to the engine that produced the scores. 0.8 on Perspective isn't 0.8 anywhere else, and even on Perspective itself a small move changes a lot. On my own benchmark (run on September 28, 2026, 2,672 toxic and 3,528 clean texts labeled blind by AI judges), Perspective at 0.7 caught 33.0% of the toxic texts and flagged 1.0% of the clean ones. At 0.479 it caught 58.4% and flagged 7.0%.

Perspective API on Unprofane's own head-to-head benchmark, run September 28, 2026

So don't copy the old number. Two things help:

Map it. The replay tool takes a CSV of recent texts with the scores Perspective gave them, and shows, for each old threshold, the threshold on Unprofane that flags the same share and how often the two agree.
Then judge it on decided comments. The same queue size doesn't mean the same comments, and agreeing with Perspective also means copying its mistakes. Run a sample your moderators already approved and removed through staging. For each candidate threshold, count the removed comments it catches and the approved ones it flags, read the disagreements, and then choose.

8. Keep a way back

Rolling back is the same argument, pointed home, with your Google key back in the environment:

discoveryServiceUrl="https://commentanalyzer.googleapis.com/$discovery/rest?version=v1alpha1"

That works until December 31. After that there's nothing to roll back to, which is the best reason to switch in November and not on the last week of December.

If you'd rather use something else

The honest version: if Perspective was only giving you a rough harassment and hate signal and you want to pay nothing, OpenAI's moderation endpoint is free. It isn't a drop-in, though. You'd rewrite the call and the parsing, its categories are harassment, hate, illicit, self-harm, sexual and violence (no profanity), and on my benchmark, at the same 7.0% clean-flagged rate, it caught 40.8% of the toxic texts.

Unprofane caught 89.0% at that rate on the same texts. That's my own benchmark on a set I built, so weigh it that way, and run your moderators' sample through whatever you pick. Its weak spots: it's a young product, it reads text only, and past the free test key you're on a paid plan.

The full guide with the test notes is here.

If it goes wrong

HttpError 400 naming an attribute: you're requesting one that isn't scored (step 6).
It still talks to Google: check that discoveryServiceUrl is passed to the build you actually run, and that static_discovery=False is there.
RESOURCE_EXHAUSTED: a test key's monthly or daily cap is used up, or your plan's month is.
A batch refused with INVALID_ARGUMENT: it's over 100 parts, 30,000 characters or 256 KiB. Send several smaller ones.

That's the whole move. The code part takes a few minutes, and the threshold part deserves a few days.

Good luck with the switch, and I hope your January is quiet :)

I make Unprofane, which checks what people type for swearing and abuse.

Why Your Profanity Filter Blocks Scunthorpe (And How to Fix It)

Tomer N — Tue, 27 Oct 2026 13:00:00 +0000

In April 1996 a man named Doug Blackie tried to sign up for AOL. He typed his name, then his hometown, Scunthorpe, and the form wouldn't take it. After some back and forth with AOL's people in Dublin, the way he finally got in was to say he lived in "Sconthorpe".

You can probably see why. Four letters inside the town's name spell a word AOL's filter was told to refuse, and the filter never looked further than that. Thirty years later, it's still one of the easiest bugs to ship in a signup form, and it has a name: the Scunthorpe problem. (Drafted with AI help; every fact is sourced.)

I want to walk through why it keeps happening, and the four ways people usually write the check, with real code and what each one gets wrong.

It's not just one town

Once you start looking, the list is long. Wikipedia keeps a page of real cases, and a few of them stuck with me:

In 2004 Hotmail refused Craig Cockburn's surname, and at first told him to spell it C0ckburn, with a zero.
The Horniman Museum in London lost email in 2004 because filters read its name as "horny man".
In 2010 Xbox Live suspended a player for saying he lived in Fort Gay, West Virginia.
In 2018 a grocery store's cake form wouldn't print "summa cum laude", and the customer's cake came out with dashes where "cum" should have been.

Every one of these is the same mistake: a word was found inside a longer word, and nobody checked what the longer word was.

Why it happens

A filter has two jobs that pull against each other.

It has to catch the bad word when it's glued to something else: "dumbass", "shithead", a username like "xXfuckfaceXx". Those don't have spaces around the bad part, so the filter has to look inside words.

And it has to leave innocent words alone, which means not looking inside words. Scunthorpe, Cockburn, classic and cockpit all contain a bad word, and none of them is one.

You can't fully do both with a list of strings. Every fix below moves the line between the two, and you get to pick where.

To keep things concrete, all four versions use this short list:

const BAD = ['cunt', 'cock', 'ass', 'shit', 'penis', 'fuck', 'clit'];

1. Look for the bad word anywhere

This is the version most of us write first, and it's what AOL had:

function findProfanity(text) {
  const t = text.toLowerCase();
  return BAD.find((word) => t.includes(word)) ?? null;
}

It catches "dumbass", "shithead" and "xXfuckfaceXx". It also blocks Scunthorpe, Craig Cockburn, "a classic mistake" and "cockpit". It's thorough in both directions, which is the problem.

2. Only match whole words

The usual next step is a word boundary in a regular expression:

const WHOLE = new RegExp(`\\b(${BAD.join('|')})\\b`, 'i');

function findProfanity(text) {
  return WHOLE.exec(text)?.[1].toLowerCase() ?? null;
}

Now Scunthorpe goes through, and so does everything else. "dumbass" isn't the word "ass", "shithead" isn't "shit", and a username has no word boundaries at all. On the eight texts in the grid further down, it blocked nothing innocent and caught none of the four rude ones.

That's fine for some products. If your users write sentences and mostly swear in whole words, this might be enough. For usernames it does almost nothing.

3. Strip an allow list, then look anywhere

So you go back to version 1 and add exceptions. The tempting way is to delete the allowed words from the text before checking:

const ALLOW = ['scunthorpe', 'cockburn', 'hancock', 'clitheroe', 'classic', 'cockpit', 'bass'];

function findProfanity(text) {
  let t = text.toLowerCase();
  for (const ok of ALLOW) t = t.replaceAll(ok, ' ');
  return BAD.find((word) => t.includes(word)) ?? null;
}

Say "bass" is on there because a music forum's users kept getting blocked. Now look at "dumbass": the last four letters are "bass", they get deleted, and the insult goes through clean. Stripping substrings has the same bug as matching them, just pointed the other way.

4. Check word by word, with a dictionary

The version I'd actually ship splits the text into words first, and only looks inside a word when that word isn't a real one:

import { readFileSync } from 'node:fs';

const DICTIONARY = new Set(
  readFileSync('/usr/share/dict/words', 'utf8').toLowerCase().split('\n'),
);
const OURS = new Set(['scunthorpe', 'cockburn', 'hancock', 'clitheroe']);

function findProfanity(text) {
  for (const word of text.toLowerCase().match(/\p{L}+/gu) ?? []) {
    if (BAD.includes(word)) return word;
    if (DICTIONARY.has(word) || OURS.has(word)) continue;
    const hit = BAD.find((bad) => word.includes(bad));
    if (hit) return hit;
  }
  return null;
}

Three things are going on here:

A word that's on the bad list by itself is blocked, even though "ass" and "cock" are also in the dictionary.
A real dictionary word is left alone, so "classic", "cockpit", "assassin", "cockatoo" and even "Penistone" pass without you listing them. macOS ships that file with 235,976 words, and Debian and Ubuntu install one with the wamerican package.
Anything else, like "dumbass" or "xxfuckfacexx", gets the substring check.

The four versions on the same eight texts, run on October 27, 2026

The dictionary doesn't know names, though. Scunthorpe, Cockburn, Hancock and Clitheroe aren't in it, which is why OURS exists. That's where you put the towns, surnames and product names your own users type. It's a much shorter list than an allow list for every English word, and it only grows when a real person hits it.

What none of these fix

Every version above missed "f.u.c.k off". Splitting on letters turns it into four single letters, and none of them is on the list. Disguises like dots, digits and look-alike letters from other alphabets are a whole separate problem, and a list of strings doesn't solve it on its own. You have to normalize the text first, and that's a post of its own.

The other gap is context. "Cock" is a rooster on a farming forum and an insult in game chat. No list can tell those apart, because the difference isn't in the word.

What I'd do

If I were adding a check to a signup form tomorrow:

Start from version 4, with a real dictionary and a short list of your own names.
Test it on text you know is clean: your users' towns, surnames and product names. Every block there is a bug.
Don't reject when you're unsure. Hold the name for a quick human look instead, so someone from Clitheroe waits a minute instead of leaving.
Give people a way to tell you. Every report is one more entry for OURS.

Doug Blackie's story is thirty years old, and the bug is still easy to write in an afternoon. The good news is the fix is too.

Thanks for reading, and good luck with your filter :)

I build Unprofane, a profanity filter API. Its Scunthorpe guide lists the innocent words filters trip on most.

7 Profanity Filters for Developers in 2026 (Perspective API Is Shutting Down)

Tomer N — Sun, 25 Oct 2026 11:34:15 +0000

If you have ever shipped a signup form, you know the moment. Somebody registers a username you really don't want on your leaderboard, and it's sitting there in the top ten by Friday.

So you add a word list. A week later they're back as sh1t, f.u.c.k or with a Greek letter swapped in, and when you tighten the list, somebody from Scunthorpe can't sign up anymore. (Written with AI help; every number here is checked against the source I link.)

And if you handed this problem to Google's Perspective API, there's a date in your calendar you may not know about: Jigsaw says the service runs until December 31, 2026, and its FAQ says access can't be extended past that.

So I went through the options developers actually reach for. Five are APIs, one is an npm package, one is on its way out. A few are free, and I'll say which. I'll also say where each one falls short, because nothing annoys me more than a "best tools" list where everything is perfect.

Let's start the list:

1. Unprofane

The unprofane.com playground

Unprofane is a profanity filter API built for the two problems at the top of this post. Full disclosure, I built this one.

You send it a username, a chat message or a review, and it answers allow, review or block, with the evidence: which words it found, where they were, how each one was disguised, and a censored copy to display. It undoes 13 measured kinds of disguise, from a swapped digit to a look-alike letter out of another alphabet.

It also answers on Perspective's path, with Perspective's JSON and Perspective's errors, so a Python or Node client moves over by changing one line, and Coral Talk or Discourse by changing two.

On the numbers: in my own head-to-head, read once on 2026-09-28 against 9,029 texts labeled blind by AI judges, it caught 89.0% of the 2,672 toxic ones while flagging 7.0% of the clean ones. Perspective, read at the threshold where it flags that same 7.0%, caught 58.4%. On the public split of the Scunthorpe Test (run of 2026-10-19) its rules flagged 0 of 549 innocent words and names, though that list is the engine's own, so it was built not to flag them. Your own innocent words are not in it.

Where it falls short: there is no free plan, only free test keys at 100 checks a day for building. It reads text, not images or video. It's a young product. And the benchmark above is mine, with labels from AI judges, not an independent lab's.

Plans start at $9 a month for 25,000 checks, half price for the first three months until December 31, 2026.

There are lots of other features also:

17 languages, each with its own words and spellings
Catches insults and threats written in ordinary words, not only listed ones
Typed SDKs for JavaScript and Python
An MCP server, so a coding agent can write the call itself

Checkout here: unprofane.com/bench

2. OpenAI Moderation

Screenshot: OpenAI's moderation guide

OpenAI's moderation endpoint is free to use, and if you already have an OpenAI key, it's one request away. That's a real advantage worth taking seriously.

The current model, omni-moderation-latest, classifies text and images into thirteen categories across harassment, hate, illicit, self-harm, sexual and violence, with their subcategories. You get a flagged boolean, plus a flag and a score for each category.

The catch for this particular job: none of those thirteen categories is profanity. It's built to find harm, not swearing. On my test set, read at the threshold where it flags the same 7.0% of clean text as the others, it caught 40.8% of the toxic texts. Its own flagged verdict catches more, 62.2%, but flags 20.6% of the clean text, which is a lot of false alarms to hand your moderators.

There are lots of other features also:

Free
Reads images as well as text
OpenAI's data controls list /v1/moderations as not used for training

Checkout here: OpenAI moderation guide

3. Perspective API

Screenshot: perspectiveapi.com

Perspective was the free default for years, and it earned that. Coral Talk and Discourse both shipped it, at a 0.7 threshold, which is why so many comment queues look the way they do.

You ask for the attributes you want, such as TOXICITY, SEVERE_TOXICITY, INSULT, PROFANITY and THREAT, and it answers with a probability for each, for the whole comment and optionally per sentence. TOXICITY is listed for seventeen languages, the other production attributes for seven.

One thing worth knowing about that 0.7 default: on my test set it flags only 1.0% of clean text there, which is lovely, but it catches 33.0% of the toxic text. Quiet queues are not the same as clean comments.

It's on this list as a warning, though. Jigsaw says the service remains active until December 31, 2026, and the FAQ says access cannot be extended past the final date. Requests for new access were taken only until February 2026. The sunset notice on its own home page adds the part that matters most if you're integrated: there will be no direct migration support. If it's in your stack today, you need a plan before then.

There are lots of other features also:

Free, with a default quota averaging one query per second per project
Experimental attributes, including ones trained on New York Times comments
A doNotStore flag, which the docs tell you to set for private text

Checkout here: perspectiveapi.com

4. WebPurify

Screenshot: webpurify.com documentation

WebPurify does more than text, and that's the reason to pick it. Its in-house team moderates images around the clock, every day of the year, and it says it doesn't crowdsource that work. Video gets AI review across 16 or more categories, with the audio transcribed and read too.

For text, its API checks against a word list it maintains, and answers with a count, the words it found, or the text with them masked. You can add your own block and allow lists per license key, by API or in the admin.

Two things to check before you build on it. The documented text responses don't tell you where each word was, what category it is, how severe it is, or how it was disguised, so you can't highlight a span or tune by category. And language isn't detected: the caller names it. Its docs list twelve languages plus three in beta.

There are lots of other features also:

Email addresses, phone numbers and URLs can count as profanity
Plugins for WordPress, Drupal, Joomla and bbPress
Endpoints in the US, the EU and Asia-Pacific
Texts up to 30,000 characters, with no cap on queries

Checkout here: webpurify.com

5. CleanSpeak

Screenshot: cleanspeak.com

CleanSpeak is the heavyweight. It's a filter plus a full moderation console: approval queues, alerts, user reputation, ban and mute tools, and reports by tag, severity and top offenders. If you have actual moderators, that console is worth more than any accuracy number.

Its filter answers well, too. Each match comes back with its position, length, matched text, root word, a severity and tags such as vulgarity, sexual or bullying. You can self-host it or let them run a private server for you, and 22 or more base language lists come included for you to edit.

Three things to know. Prices aren't published, so you'll be talking to sales. The machine-learning models cost extra, and its features page says those models come from Google Perspective, which ends after December 31, 2026; I couldn't find a page that says what happens to them then. And self-hosting wants MySQL 8 or Postgres 10 and an OpenSearch or Elasticsearch cluster beside it.

There are lots of other features also:

Filters for email addresses, phone numbers, URLs and usernames
An allowlist mode for children's chat
Webhooks for approvals, user actions, edits and deletes
A 30-day free trial with no credit card

Checkout here: cleanspeak.com

6. Azure AI Content Safety

Screenshot: Azure AI Content Safety docs

If you're already on Azure, this is the natural place to look, and keeping it in one bill is a genuine reason to choose it.

It reads text and images for four harm categories: hate and fairness, sexual, violence and self-harm. Each comes back with a severity, 0 to 7, or four levels by default. You get a categoriesAnalysis array and, if you use blocklists, the list name and the item that matched.

Profanity isn't a category here. Microsoft's own harm-category docs put curse words, profanity and insults that don't target an identity group at level 2 of hate, the lowest band above nothing. So a plain "is this rude?" answer means tuning thresholds rather than reading a field. You'll also need an Azure subscription and a resource in a supported region before your first call.

There are lots of other features also:

Your own blocklists, stored in your resource's region
Prompt Shields for LLM apps, plus groundedness detection in preview
Inputs not stored during detection and not used for training
Trained and tested on eight languages; others may work at varying quality

Checkout here: Azure AI Content Safety

7. obscenity (npm)

Screenshot: obscenity on GitHub

If you don't want an API at all, obscenity is the npm package I'd reach for. It runs inside your own Node process, which means no network call, no per-check cost, and the text never leaves your server.

It matches more than an exact string: repeated letters, look-alike Unicode letters, and a word hidden inside a longer one. It tells you where each match is and can censor it for you. It's MIT licensed, and you can add your own words on top of the built-in list.

Its README is honest about the limit, and says to treat the output as a heuristic. A word list reads words, not meaning, so "nobody wants you here" goes straight through, and so does a disguise nobody has added yet. For a side project, that trade is often exactly right.

There are lots of other features also:

Zero cost and no network latency
Works anywhere Node runs
Your own word list on top of the default English one

Checkout here: github.com/jo3-l/obscenity

That's the list.

How I'd pick, honestly:

You want harassment and self-harm flags more than swearing, for free: OpenAI Moderation.
You need images or video moderated, or people in the loop: WebPurify.
You have moderators and want them a console: CleanSpeak.
You're already deep in Azure: Content Safety.
It's a side project and a heuristic is fine: obscenity, for nothing.
Usernames and chat that people will deliberately spell around, or a Perspective integration to replace: that's the gap I built Unprofane for, and the migration guide is at unprofane.com/perspective.

One last thing, whichever way you go. The 0.7 threshold everybody inherited from Perspective is a choice, not a default, and it's a quiet one. Measure your own false alarms before you ship, on your own text, in your own languages. Every number in this post came with a false-alarm rate beside it for exactly that reason.

If you've built a filter yourself, or you've seen a disguise none of these catch, drop it in the comments. I'm always looking for the next one.

Thanks for reading :)

I build Unprofane, an API that decides whether a text is profane.

Google Is Shutting Down Perspective API on December 31. Here’s What Breaks, and When

Tomer N — Sun, 25 Oct 2026 10:58:42 +0000

December 31, 2026 is the last day Google's Perspective API will answer. Jigsaw's own notice puts it plainly: the service "will remain active until December 31, 2026." There's no extension and no migration help from Google.

I went through what happens to the tools built on top of it, and the answer surprised me. Most of them won't crash on January 1. They'll keep accepting comments and quietly stop checking them. (AI-assisted draft; I checked each claim against its source.)

So here's the whole picture, by date, with the steps I'd take if Perspective sits anywhere in my stack.

The dates

From Google's notice at perspectiveapi.com

February 2026: requests closed. Google stopped taking usage and quota increase requests in February. If your traffic grew this year, you're living on whatever quota you already had. The FAQ puts the default at an average of one query per second per project.

Now until December 31: it still works. Nothing has changed in the API itself. Same endpoint, same JSON, still free. That's the catch, honestly. There's no warning in the response, so nothing in your logs will remind you.

January 1, 2027: no more answers. Google hasn't said what the endpoint will return after that, whether it's an error code, a timeout or a domain that doesn't resolve. So plan for all three.

What actually breaks

A lot of Perspective calls don't come from code you wrote. They come from comment systems, forum plugins and old scripts, and each of those decided long ago what to do when Google doesn't answer. I read the code for two that ship it built in.

Coral by Vox Media (a comment platform for news sites). Coral's toxic comment filter sends each new comment to Perspective and holds anything above your threshold for a moderator. If the call fails, its code logs "could not determine comment toxicity" and moves on. The comment goes through the rest of the pipeline as if it were clean. No alert, no error for the reader, no item in the queue.

Coral's toxic.ts on GitHub: a failed call is logged, and the comment moves on

Discourse's Perspective plugin. The official plugin flags posts above a toxicity threshold and can warn people while they type. Two failure paths here. If the network call itself fails, it raises an error and the post isn't flagged. And if Google answers with an error body instead of scores, the plugin's parser falls back to a score of 0.0 for every post. Zero never crosses a threshold, so nothing gets flagged.

Your own code. If you call the API directly, what happens depends on one line you probably wrote years ago: the except around the call. A lot of moderation code is written to fail open on purpose, because nobody wants a Google outage to block every comment. That was the right call for a five-minute outage. It's the wrong call for a permanent one.

Research pipelines. If a paper, a dataset or a dashboard depends on fresh Perspective scores, it stops being reproducible on new text in January. Scores you already stored still exist, but you can't add comparable ones.

Who should care

Newsrooms and publishers running Coral with the toxic comment filter on.
Discourse forums with the discourse-perspective-api plugin enabled.
Apps calling commentanalyzer.googleapis.com from a backend, a queue worker or a serverless function.
Teams with a dashboard or a study built on TOXICITY scores.

If you're not sure, the next step tells you in a minute.

The steps, in order

1. Find every call

Search your code, your config and your infrastructure for the host name:

grep -rn "commentanalyzer" .

Also check the admin settings of anything you didn't write. In Coral it's under Configure, Moderation, Toxic Comment Filter. In Discourse, type "perspective" into the admin settings filter. And look for the API key in your Google Cloud project, since forgotten scripts love to share one.

2. Make failures loud

Before you replace anything, change what happens when the check doesn't answer. Even if you switch next week, this protects you from the next outage too.

def check_comment(text):
    try:
        return score(text)  # your current toxicity call
    except Exception:
        log.error("toxicity check failed, holding comment for review")
        return None  # treat None as "send to the review queue"

The rule is simple: an unanswered check goes to a human or to a hold, never straight to publish. And add an alert on the error count, so a dead endpoint pages someone instead of filling a log nobody reads.

3. Save what your thresholds mean

Your thresholds were tuned against Perspective's scale, probably over months. Before December, export a sample of recent comments with the scores Perspective gave them and what your moderators decided. Any replacement will score on its own scale, and that sample is how you'll find the new threshold that flags about the same share of comments.

4. Pick a replacement and run it side by side

Run the new service in parallel for a week or two, logging both answers, before you switch. The main options, with their trade-offs:

OpenAI's moderation endpoint. Free, and it scores harassment, hate, self-harm, sexual content and violence. It has no profanity category, so swearing on its own won't move it.
Azure AI Content Safety. Hate, sexual, violence and self-harm on a severity scale. Needs an Azure subscription; plain profanity that doesn't target a group sits at a low level of hate.
Discourse AI. For Discourse forums, its AI triage can classify posts with an LLM prompt you write. Discourse-hosted sites can use Discourse's own hosted small LLM; self-hosted forums need a third-party one.
A word list. Coral and Discourse both have banned words built in. It's free and predictable, but it misses disguised spellings and can block innocent words.
A drop-in for Perspective's API. Full disclosure, I built Unprofane, which answers Perspective's own requests on the same path with the same JSON, so Coral moves by changing an endpoint and a key, and Discourse by a one-line change to its plugin. The migration guides cover each client.

None of these is a perfect clone, since each model scores differently. If you mostly care about threats and harassment and want free, OpenAI is a reasonable first test. If you have an LLM in your forum already, Discourse AI keeps everything in one place.

5. Switch before December, keep a way back

Don't plan the switch for the last week of the year, when half your team is out. Pick a date in November, keep the old key working until the end of December, and make the endpoint a config value so rolling back is a settings change, not a deploy.

6. Clean up in January

After the switch, delete the Perspective key from your Google Cloud project and remove the old code path. A dead integration that still "works" is how the failure in step 2 sneaks back in a year later.

The short version

Perspective's last day is December 31. The real risk isn't a broken page, it's moderation that silently turns off. Find your calls, make failures hold comments instead of publishing them, save your old scores, test a replacement in parallel and switch in November.

If you're in the middle of this and hit something odd, tell me in the comments. I'd like to know which tools I missed.

Good luck with the switch, and thanks for sticking with me to the end :)

I'm the developer behind Unprofane, a profanity and toxicity API.