Broken Char

Clean code detection

A CLI tool to detect problematic characters in codebases. Finds control characters that display as red blocks, emojis in source code, excessive punctuation patterns, and potential AI-generated content markers. Available on NPM and GitHub.

Detects invisible control characters that display as red blocks or cause mysterious parsing errors
Finds emojis and special characters that may indicate AI-generated or copy-pasted content
Identifies punctuation patterns like excessive em dashes common in AI output
Integrates with build pipelines to catch issues before they reach production

Analyze

Finding the right problem

I do a lot of documentation work and needed a way to ensure everything was encoding correctly across front-end, back-end, and technical docs. There was no existing tool that could find all the inconsistencies and help me set a standard.

Invisible control characters slip into code through copy-paste and cause VS Code to display red blocks
AI-generated code often includes em dashes, curly quotes, and excessive punctuation that breaks in certain contexts
Existing linters focus on syntax and style, not character encoding or Unicode anomalies
Developers I talked to had all encountered "phantom bugs" caused by invisible characters

Character encoding is the debugging problem nobody thinks about until it costs them hours.

Create

Building and shipping

I built the tool in Node.js for cross-platform compatibility and easy NPM distribution. The MVP focused on comprehensive detection with sensible defaults.

Severity levels distinguish critical issues from warnings so users can focus on what matters
Smart defaults ignore common directories like node_modules and build outputs automatically
Configurable checks let teams disable categories when certain patterns are intentional
Output formats support both human-readable reports and machine-parseable results for automation

Sensible defaults prevent the tool from creating new problems.

Evaluate

Learning and iterating

User feedback shaped the tool's flexibility. Different teams have different tolerance levels for non-ASCII content, so configurability became essential.

The severity flag was added after users wanted to focus only on critical control characters without noise
Ignore patterns for specific directories came from teams with third-party code they couldn't modify
Summary mode was requested by users who wanted quick pass/fail checks without detailed output
The comprehensive non-ASCII mode was added for teams with strict ASCII-only requirements

Localization files taught me that legitimate Unicode requires escape hatches, not blanket rules.