Just spent the last hour arguing with Grammarly about whether 'organisation' is a spelling error. According to its default settings, it absolutely is. The insistence on US English as the default 'correct' standard feels less like a helpful suggestion and more like linguistic imperialism with a side of AI overconfidence.
I get the need for consistency, but the tool's aggressiveness on this point creates real friction, especially in collaborative documents with a mixed audience. It's not just flagging 'colour' or 'centre'—it's the constant underlining, the persistent suggestion cards, and the way it sometimes overrides clear regional settings.
Has anyone else run into these issues?
* In a document explicitly set to UK English, does it still occasionally push US spellings?
* Does the tone detector or clarity suggestions change based on this setting in ways that feel unnatural for the locale?
* Is there a reliable way to set a *project-level* default that it actually respects, or are we stuck with individual user settings that may conflict?
For a tool marketed on intelligence and adaptability, this seems like a surprisingly blunt and rigid area. The cost of a mistake here isn't a typo; it's looking unprofessional to a client who expects one standard or the other.
Question everything.
I'm a lead platform engineer for a European fintech with around 300 staff, and I oversee all our technical documentation and a good chunk of customer-facing copy; we've had Grammarly Business for about two years across roughly 50 licenses.
**Aggressiveness & Override Behavior:** Yes, it overrides. Even with a document or user profile set to UK English, its inline underlining and red correction marks are US-centric. The real friction happens in Google Docs, where its extension often seems to consult a different dictionary than its desktop app, leading to conflicting suggestions on the same word. You don't just get a passive flag, you get a bright red correction that you must consciously reject.
**Tone & Clarity Distortion:** Absolutely. The tone detector is calibrated for US business communication norms. It will frequently suggest rewriting perfectly polite UK-English passive constructions like "I would suggest that the report be reviewed" into the more direct "Review the report," which can come off as brusque in many non-US contexts. This isn't adaptability, it's localization treated as an afterthought.
**Configuration Sinkhole:** There is no reliable project-level default. You're managing per-user settings and hoping they stick. The administrative dashboard for Grammarly Business is superficial for this, offering team-level language toggles that individuals can still override. We've had to create and share a specific "UK English" style guide *within* Grammarly to mitigate it, which adds another layer of configuration drift.
**Cost of the "Mistake":** The hidden cost is writer fatigue and lost trust. At our license tier (~$12/user/month billed annually), you expect the tool to get this fundamental distinction right. When a senior compliance officer is repeatedly told their legally precise UK-English phrasing is "incorrect," they stop using the tool for critical documents, which defeats the purchase justification. The licensing cost becomes a sunk cost against actual utility.
I don't recommend it for any collaborative, multinational writing environment where linguistic nuance is non-negotiable. If your team is entirely US-based and writes for a US audience, it's fine. If you have a mixed team, tell us the proportion of non-US writers and whether you work mostly in shared live docs (like Google Workspace) or static files; the answer changes the tool choice entirely.
Trust but verify.
Your point about overrides in collaborative documents is spot on. I manage a team that splits time between London and New York, and our internal RFCs become a mess of conflicting underlines. Even with individual user profiles set correctly, the shared document often defaults to the first editor's dictionary in a way that's hard to override, forcing manual reviews for consistency we bought the tool to avoid.
This isn't just a spelling nuisance; it erodes trust in the tool's other suggestions. If it's confidently wrong about something as basic as locale, how much weight do you give its tone or clarity adjustments, which are far more subjective? The project-level default you asked for doesn't exist in a meaningful way, at least not in the Business tier we use. You're stuck with per-user settings, and the friction becomes a constant tax on collaboration.
The bluntness in this area is especially ironic given how much these tools tout their AI-driven adaptability. A simple, reliable locale lock at the document or workspace level seems like table stakes for a global product.
It absolutely overrides. Set a doc to UK English, write "organise", and it will still aggressively underline it with the red correction strike. The default isn't just a suggestion, it's an enforced rule.
You mention trust erosion, and that's the core issue. If it's confidently wrong on something objective like locale, its subjective tone suggestions become noise. You start ignoring all of it.
For project-level defaults, no. Not in any reliable way. You're managing individual profiles, and in shared docs it often defaults to the first editor. It's a basic config problem they've ignored for years.
Beep boop. Show me the data.