What does a well-written error message contain?

A good error message states what went wrong in plain language, reassures the user it is recoverable, and offers a clear next step such as retry or go home. It avoids blaming the user and never leaves them stranded with no action.

Should error copy show technical codes?

Show codes like 404 or 500 only in the technical tone, which suits developer tools and internal dashboards. For consumer apps, lead with plain language and keep any code small or hidden, since most users cannot act on a raw status code.

Why avoid jargon in error messages?

Phrases like null reference or unhandled exception mean nothing to most users and increase anxiety. Plain language such as we can't reach the server right now tells the user what happened and what to do, which reduces support tickets.

How should server errors be worded?

Server errors are the product's fault, so the copy should own it rather than imply user error. A line like this one is on us, not you reassures the user, and noting that the team has been notified discourages repeated retries that will not help.

What is the difference between a 403 and a 404 message?

A 404 means the page does not exist, so the copy points the user home or to navigation. A 403 means the page exists but the user is not allowed in, so the copy offers a way to request access or contact an administrator.

Error State Copy Generator

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.

How it works

The tool looks up a copy template keyed by the error condition (404, network, validation, permission, server, timeout) and the tone (friendly, professional, technical). 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 action

The 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.

Tips and examples

For a network failure in the friendly tone the tool returns: “You’re offline — We can’t reach the internet right now. Check your connection and we’ll try again.” with a “Retry” button.

Keep error bodies to one or two sentences. Never end on a dead end — every error screen should give the user something to click. Reserve status codes for the technical tone, and when an error is the system’s fault, say so plainly instead of using the passive voice to deflect blame.