--- title: "php-typos: a fast spellchecker for PHP codebases (Tool Review)" url: https://www.exakat.io/php-typos-a-fast-spellchecker-for-php-codebases-tool-review/ date: 2026-06-30 modified: 2026-06-30 author: "dams" description: "php-typos: A Fast Spellchecker for PHP Codebases (Tool Review) There's a particular kind of embarrassment reserved for the typo that ships to production. A recievePayment() method. A config key spelled..." categories: - "Technology" tags: - "audit" - "semantics" - "typos" image: https://www.exakat.io/wp-content/uploads/2026/06/header-dark.png word_count: 1215 --- # php-typos: a fast spellchecker for PHP codebases (Tool Review) # php-typos: A Fast Spellchecker for PHP Codebases (Tool Review) There's a particular kind of embarrassment reserved for the typo that ships to production. A `recievePayment()` method. A config key spelled `treshold`. A comment that confidently explains the "lenght" of an array. None of it breaks anything, all of it makes the codebase look a little less cared-for, and most linters won't say a word about it. [php-typos](https://github.com/chr15k/php-typos) by chr15k sets out to catch exactly this class of problem. It's a source-code spe[![](https://www.exakat.io/wp-content/uploads/2026/06/header-dark-300x300.png)](https://www.exakat.io/wp-content/uploads/2026/06/header-dark.png)llchecker for PHP projects, and the headline pitch is speed: it's *fast*. Having spent some time with it, here's where it shines and where it still has room to grow. ## What it is php-typos is a Composer package that scans your PHP source for spelling mistakes in comments, strings, and identifiers, then optionally fixes them. Under the hood it's a wrapper around the excellent [`typos`](https://github.com/crate-ci/typos) Rust CLI from crate-ci, which is where the blistering performance comes from. The clever part is the packaging: the correct platform binary ships with the package, so there's no Rust toolchain, no Cargo, and no Homebrew to set up. You install it like any other dev dependency and run it the same way you'd run Pint or PHPStan. Getting started is genuinely a two-step affair: ``` composer require chr15k/php-typos --dev ./vendor/bin/typos --init ``` The `--init` step drops a `_typos.toml` into your project root, where you configure paths to exclude and words to ignore. From there, a bare `./vendor/bin/typos` scans the whole project, or you can point it at specific directories like `app/ tests/ config/`. It targets PHP 8.3+ and ships binaries for Linux (x86*64/ARM64), macOS (Intel and Apple Silicon), and Windows (x86*64). ## The good **It's genuinely fast.** This is the first thing you notice and the main reason to reach for it. Because the heavy lifting is done by a native Rust binary rather than PHP iterating over your files, scanning even a large project feels instant. That speed is what makes it viable to run on every commit or in CI without anyone grumbling about build times. **The fix workflow is well thought out.** A spellchecker that only complains is half a tool. php-typos gives you a `--write` flag that applies corrections directly to the affected files, and — importantly — a `--diff` flag that shows you a unified diff of what *would* change first. That review-before-you-commit step matters a lot here, for reasons I'll get to below. The two flags are mutually exclusive, which is the right call. **Output formats cover both humans and machines.** The `--format` flag gives you `long` (the default, with full file/line/correction detail), `brief` (one line per file), and `json`. The human-readable modes are pleasant to read, and the JSON output is the bit that makes this tool a good CI citizen — you can pipe it into annotation tooling so typos show up inline on pull requests rather than buried in a log. There are also handy introspection flags like `--files`, `--identifiers`, and `--words` for seeing exactly what the scanner is looking at. **It slots into existing pipelines cleanly.** Because it behaves like Pint or PHPStan, dropping it into a Composer `ci` script or a GitHub Actions step is trivial: ``` - name: Check for typos run: ./vendor/bin/typos --format=json ``` For a tool whose whole value proposition is "low friction," that consistency with the tools PHP developers already use is exactly right. ## The rough edges For all that, php-typos inherits some real limitations, and a couple are worth weighing before you adopt it. **English only.** This is the big one, and it comes straight from the underlying `typos` engine. The Rust tool is built around a curated list of English typo-to-correction mappings rather than a swappable dictionary, and its `locale` option only switches between English dialects — not between languages. If your codebase has German, French, or Spanish comments, identifiers, or domain terms, php-typos has nothing to offer them and will likely flag perfectly correct words as mistakes. Multi-language support would dramatically widen who this tool is useful for, and right now it simply isn't there. **Weak handling of composed words.** Related to the above, support for compound and domain-specific words is thin. Code is full of conjoined terms and jargon that aren't "real" dictionary words, and a spellchecker that understood common coding conventions — or could be taught your project's vocabulary more gracefully than a flat ignore-list — would produce far fewer false positives. You *can*whitelist words in `_typos.toml`, but it's a blunt instrument compared to genuine awareness of how developers compose identifiers. **No understanding of PHP's structure.** This is the limitation I'd want every adopter to internalize. php-typos treats your code as text; it doesn't know the difference between a typo in a comment and a typo in a class name. Fixing a misspelled word in a comment is harmless. Auto-fixing a misspelled *property name*, *method name*, or *class name* is another matter entirely — those are part of your public surface and your runtime behaviour. A rename that `--write` happily applies could break a magic method, a serialized property, a reflection-based lookup, an API contract, or a dozen other things that a pure text tool can't see. The `--diff` flag is your friend here, and I'd treat blind `--write` on identifiers as something to do consciously rather than reflexively. A PHP-aware version that distinguished "safe to auto-fix" comment text from "needs human judgement" identifiers would be a substantial step up. **It's a thin wrapper.** None of the above is a knock on the author's effort — packaging a cross-platform binary so it "just works" via Composer is a genuinely nice piece of developer experience. But it does mean php-typos is fundamentally a convenience layer over someone else's binary. A more idiomatic, PHP-native implementation — one that could parse PHP properly, reason about identifiers versus comments, and grow language and compound-word support on its own terms — would be a more powerful and more maintainable foundation in the long run. It's also worth noting this is an early-stage project (it's still in the 0.x versions, with a small but active release history), so some of these gaps are exactly what you'd expect from a young tool finding its feet. ## The verdict php-typos is a nice, fast tool that does a real job well. If you have an English-language PHP codebase and you want to stop shipping typos in your comments and strings, it's an easy win: quick to install, quick to run, friendly in CI, and equipped with a sensible fix-and-review workflow. For that use case, it earns its place alongside Pint and PHPStan in a project's quality toolchain. The caveats are about ambition rather than execution. English-only support, limited handling of composed words, and a lack of PHP-structural awareness all cap how far you'd want to trust it — particularly the auto-fixer on anything that isn't plain prose. Lean on `--diff`, keep `--write` for the safe stuff, and you'll get a lot of value out of it today. Where I'd love to see it go: multi-language support, smarter handling of coding conventions and compound words, and ideally a more idiomatic PHP-native core that understands the code it's checking rather than treating it as a wall of text. The bones are good. There's room for this to become something more than a fast wrapper.