Error states are some of the most-seen screens in any app, yet they are often written last and badly. A clear error message tells the user what happened, that it is fixable, and what to do next. This generator produces that three-part copy for the six most common error conditions in three tones — friendly, professional, and technical — ready to paste directly into your UI.
How it works
The tool looks up a copy template keyed by the error condition and the tone. Every template returns the same structure that UX writing guides recommend:
heading — what happened, in a few words
body — why it happened and that it is recoverable
cta — the single best recovery actionThe recovery action is matched to the error: retry for transient network and timeout errors, go home for a 404, request access for a 403, and review fields for a validation failure. Server errors deliberately take ownership of the fault rather than implying the user did something wrong.
The six error conditions and when to use each
404 Not Found — The URL exists in neither the app’s router nor the server. Good copy points the user back to navigation rather than explaining HTTP. Avoid “page not found” as the only text — tell them what they can do.
Network / Connectivity — The device cannot reach the server. The cause is almost always client-side (Wi-Fi dropped, airplane mode, VPN). The copy should be calm, blame nothing, and offer one retry tap.
Validation Error — The user submitted a form with missing or incorrectly formatted fields. Copy must name the specific field(s) that failed, not a generic “please fix the errors” banner. Inline field-level messages beat page-level messages every time.
Permission Denied (403) — The resource exists but the user lacks access. Copy should distinguish between “you need to sign in” and “you don’t have permission and can request it” — these require different recovery paths.
Server Error (500) — The app is at fault, not the user. Own it. Something like “This is on us” reduces user anxiety and cuts misdirected support tickets. Include a timestamp or reference number in the technical tone so users have something concrete to send support.
Timeout — The server took too long. Often indistinguishable from a server error from the user’s perspective. The best copy is the same as a network error — retry is the recommended action.
Tone comparison
| Condition | Friendly tone | Professional tone |
|---|---|---|
| Network | ”You’re offline — check your connection" | "Unable to connect. Please verify your network.” |
| 404 | ”That page got lost in space" | "Page not found” |
| Server error | ”This one’s on us" | "An unexpected error occurred” |
| Timeout | ”Things are running slow — hang tight" | "The request timed out. Please try again.” |
What makes error copy genuinely good
Never leave a dead end. Every error screen needs a next action — a button to retry, navigate home, contact support, or go back. A message that explains the problem but offers no path forward has failed the user.
Match fault to voice. When the user made a mistake (validation), be direct but not accusatory — “Email address is required” beats “You left a field blank.” When the system made a mistake (500, timeout), accept responsibility — passive voice (“an error occurred”) feels evasive.
Length. One sentence of body text is usually enough. Two at most. Error states are not the place for detailed explanations — users want to get past the problem, not understand it.
Technical codes. Show status codes (404, 500) only in developer tools and internal admin dashboards. Consumer apps hide codes or put them in small text below the human-readable message. The code means nothing to most users and adds visual noise.