Docs: Italian Profanity Filter for JS, TypeScript & Flutter

Quick start

Use the JavaScript package in Node or browsers, or the pure Dart package in Flutter. Both share their detection rules and expected results.

JAVASCRIPT / TYPESCRIPT

npm install italian-profanity

import { createChecker } from "italian-profanity";

const checker = createChecker({
  profile: "balanced",
  languages: ["it"],
  contacts: false,
  maxLength: 64,
});

const result = checker.check("D10 p0rc0");
if (result.action === "block") {
  // Reject the submitted nickname.
}

DART / FLUTTER

flutter pub add italian_profanity

import 'package:italian_profanity/italian_profanity.dart';

final checker = ItalianProfanity.createChecker(
  profile: Profile.balanced,
  languages: ['it'],
  contacts: false,
  maxLength: 64,
);

final result = checker.check('Claudio');
if (result.action == Action.block) {
  // Reject the submitted nickname.
}

For Dart packages outside Flutter, run dart pub add italian_profanity.

API

Four entry points are shared between TypeScript and Dart:

Function	Use it for
`check(text)`	Get an action (`allow`, `review` or `block`) and the matches.
`findMatches(text)`	Inspect detected rules without applying a moderation decision.
`isClean(text)`	Return true only when the action is `allow`, not `review`.
`createChecker(options)`	Reuse the same policy, languages, exceptions and settings across checks.

A match describes its category, severity, confidence and location in the original string. Locations are UTF-16 offsets; treat them as potentially sensitive.

Policies

Balanced

The default, designed to reduce false positives on common names.

Strict

More restrictive with ambiguous wording. Review its impact before deployment.

Lenient

Less restrictive for products where warnings may be more useful than rejection.

Make your product policy explicit. If you have no manual review queue, you might reject only block and handle review separately. Do not assume isClean() makes that distinction for you.

Customization

Languages: Italian is on by default. Enable curated English coverage with languages: ["it", "en"].
Contacts: Optional detection for URL, email and phone-like text via contacts: true.
Extra rules: Add product-specific whole-word rules rather than changing the shared dataset.
Exceptions and thresholds: Tune category sensitivity without rewriting the detector.

The full integration guide covers the option contracts and migration from existing filters.

Open integration guide ↗

Production notes

Recheck on your server. Client-side checks improve UX but can always be bypassed.
Keep versions aligned. Share the same release and options across backend and mobile clients.
Validate input length separately. A filter may inspect only the configured prefix of long text.
Protect privacy. Avoid saving actual nicknames, matches or offsets in moderation telemetry.
Review release behavior diffs. New rules may change decisions for previously allowed input.

Limitations

A lexical filter is not full moderation.

The library does not understand intent or context and cannot guarantee that an allowed input is appropriate. Some ambiguous names deliberately produce review.

Regional dialects are only partially covered. The optional English dataset is curated, but is not equivalent to a complete English-language moderation service. Evaluate the library on real use cases before enforcing strict blocking.

See something missing?

Reproducible examples and carefully reviewed exceptions help the project improve.

Open an issue

LESS GUESSWORK.MORE CONTROL.