Nobody reads your marketing page as closely as they read your 400 error. When something breaks, your error message IS the product. Yet error copy is usually written last, by whoever fixed the bug.
The Four Consistency Rules That Matter Most
-
One sentence structure - pick one pattern like
{what} is invalid: {reason}and keep it everywhere - Imperative, not apologetic - "Upload failed: file exceeds 10 MB limit." beats "Sorry! It seems the file could not be uploaded :("
-
Parallel placeholders - "Invalid
user_id" in one endpoint and "invalid userId" in another means users can't trust either - No hedging - state the fact or say nothing
The Hard Part: Copy Full of Code
Error strings are prose wrapped in code: placeholders like {} or %s, parameter names, status codes. A generic grammar checker sees Cannot find user with id {user_id} and offers to "fix" the placeholder - breaking interpolation at runtime. That is why microcopy never gets a grammar pass: the tools were never safe for it.
A code-aware checker like Lint leaves placeholders and identifiers untouched and checks only the natural language - making it finally practical to grammar-check error strings before release.
A 20-Minute Error-Copy Audit
- Export every user-facing string (errors, empty states, toasts, validation hints)
- Run a code-aware grammar check; reject anything touching a placeholder
- Check tone consistency - a marketing-voice error page next to a robotic validation hint feels broken
- Normalize terminology against your API docs
Users judge your product hardest at its failure points.
👉 Try Lint free - 3 checks/day, no signup. BYOK: unlimited, $0.
Top comments (0)