How to Design Better Error Messages That Save the Sale

Here’s the thing about error messages: they only ever appear at the worst possible moment. Someone is mid-purchase, mid-signup, mid-password-reset — they’re already a little stressed, already investing effort in you — and suddenly a red box pops up. What that box says decides whether they recover and finish, or rage-quit and never come back. If you want to know how to design better error messages, the answer fits in one sentence: tell people what happened in plain words, why it happened if that’s genuinely useful, and exactly how to fix it — without blaming them, without wiping their work, and in a tone that matches how serious the moment is. That’s the whole craft. The rest of this article is me showing you how to actually do it.

And okay, let’s be honest — error messages are nobody’s favorite project. They’re written last, usually by a developer at 11pm, usually as a placeholder that ships. But they’re conversion infrastructure. They’re also, quietly, kindness infrastructure. A good error message is your product being decent to someone on their worst click of the day.

How to design better error messages: the three-part formula

Every good error message — on a form, a checkout, a login screen, anywhere — passes the same three-part test. Judge every error in your product against it:

• 1. What happened, in plain words. Not a code, not jargon, not “an error occurred.” A human sentence a stressed person can parse in two seconds: “We couldn’t save your changes.”
• 2. Why — but only if the why helps. “Your session timed out after 30 minutes of inactivity” is useful; it tells someone the problem isn’t them. “Error code 0x80070057” is not a why, it’s a shrug. If the reason doesn’t help the person decide what to do next, skip it.
• 3. Exactly how to fix it. The single most common failure is the dead-end error: a message that announces a problem and offers no path forward. Every error needs a next step — a field to correct, a button to retry, a link to support. If there is truly nothing the user can do, say that honestly and tell them what you’re doing: “Something broke on our end. We’ve been notified — please try again in a few minutes.”

Notice what’s not in the formula: blame. The no-blame rule is central to how to design better error messages, and it’s mostly a grammar trick. “You entered an invalid email address” points a finger. “That email address is missing an @ — mind double-checking it?” describes the situation neutrally and moves straight to the fix. The user’s behavior doesn’t change; the feeling does. People forgive products that treat their mistakes as no big deal. They quietly resent products that scold them.

Why do error messages matter for conversion?

Because of when they happen. An error never interrupts someone browsing idly. It interrupts someone who has already decided — to buy, to sign up, to send you a message. These are your highest-intent visitors at their single most fragile moment, and the error message is the only thing standing between “minor speed bump” and “abandoned cart.”

Here’s the part nobody tells you: you don’t need industry statistics to make this case internally (and honestly, you shouldn’t trust generic ones — measure your own). Just pull your analytics and look at what happens after an error fires. How many people who see a checkout error complete the purchase anyway? How many who hit a signup validation error finish signing up? That recovery rate, measured against your own baseline, is the business case. In most products I’ve audited, the drop-off after an error is dramatic enough that nobody argues about prioritizing the rewrite.

Error messages sit in the same family as your other high-stakes micro-moments — the same thinking behind optimizing your login and signup forms applies here, because forms are where most errors live.

The hall of shame: five terrible error messages, rewritten

Let’s make this concrete. Here are the five classic offenders, why each one fails the three-part test, and a rewrite you can adapt. (Swap in your own product’s details — the pattern is what matters.)

Before	Why it fails	After
“An error occurred.”	No what, no why, no fix. The purest dead end in software.	“We couldn’t save your post. Your draft is safe — please try again, and if it keeps happening, our support team can help.”
“Invalid input.”	Doesn’t say which field, what’s wrong, or what valid looks like.	“Phone numbers need 10 digits — it looks like this one has 9. Mind adding the missing digit?”
“ERR_CONN_RESET: java.net.SocketException at line 2847”	Raw codes and stack traces belong in your logs, never on screen. To a user this reads as “the product is broken and so is the team.”	“We lost the connection for a second. Your work is saved — click Retry to pick up where you left off.” (Log the stack trace server-side; optionally show a short reference ID support can look up.)
“You entered an invalid expiration date.”	Blamey. “You” + “invalid” = scolding, at the exact moment someone is handing you money.	“That expiration date looks like it’s in the past — want to double-check the card?”
“Submission failed.” (form clears itself)	A dead end and it destroyed ten minutes of typing. This is the cardinal sin — more on it below.	“We couldn’t send your message just now — everything you wrote is still here. Please try again in a moment.”

Run every error string in your product through that same before/after exercise. Most rewrites take under a minute once you’ve internalized the formula. The hard part isn’t the writing — it’s finding all the errors, which is why you’ll want the audit worksheet at the end.

How do you design better error messages for forms?

Forms are where errors cluster, so they deserve their own rules. Five of them.

1. Put the error at the field — and add a summary when there are several

An error message that appears at the top of the page while the broken field sits unmarked three screens down is a scavenger hunt. Inline errors — right next to the field, with the field visually marked — are the baseline. When multiple fields fail at once, add a summary at the top (“3 fields need attention”) with links that jump to each field. Inline tells them what to fix; the summary tells them how much is left. On long forms, both.

2. Show errors at the right time — not every keystroke

Premature validation is rage fuel. If your email field flashes red the instant someone types “j” — because “j” isn’t a complete email address yet — you’re scolding people for being mid-thought. Validate on blur (when they leave the field) or on submit, not on every keystroke. The one lovely exception: once a field has already shown an error, you can switch to live validation so the red clears the moment they fix it. Reward the correction instantly; never punish the attempt early.

3. Preserve their input. Always. This is the cardinal sin.

If I could make you adopt exactly one rule from this entire article, it’s this one: an error must never wipe the form. Someone just spent ten minutes writing a thoughtful message or carefully entering shipping details; your validation failed one field; and your page reloaded blank. That person is not retyping it. They’re gone — and honestly, fair enough. Test this deliberately: fill out every form in your product, force an error, and check that every character survives. Password fields are the one accepted exception for security reasons; everything else must persist.

4. Say the format you want before they get it wrong

The best error message is the one that never fires. Prevention beats correction every time: if your phone field needs a country code, say so under the field, before anyone types. If the date must be MM/DD/YYYY, show it. A line of microcopy costs you nothing and deletes an entire category of errors. While you’re at it, question whether each strict format rule needs to exist at all — accepting “(555) 123-4567” and “5551234567” alike is kinder than any error message about either. Fewer rules, fewer fields, fewer decisions: it’s the same mercy behind reducing choice overload, applied to inputs instead of options.

5. Show password rules upfront, not as a surprise

Nothing sours a signup like typing a password, hitting submit, and then learning it needed a symbol, a number, and an uppercase letter. List the requirements under the field from the start, and check them off live as each one is met. It turns a potential scolding into a tiny progress bar. This applies to every gated form you own — signup, checkout account creation, even the humble contact form (which has its own quiet conversion leaks — here’s how to optimize your contact page end to end).

How should you handle payment and system errors?

Payment errors deserve special care, because they combine maximum stakes with maximum embarrassment. A declined card can mean a typo, an expired card, a bank’s fraud filter, or a genuine funds issue — and the person on the other side may be feeling a flush of shame regardless of which it is. Handle it with dignity:

• Stay neutral. “Your card was declined” is factual and enough. Never “insufficient funds,” never anything that speculates about someone’s finances on screen.
• Offer next steps, plural. “You can double-check the card details, try a different card, or contact your bank — your order is saved and waiting.” Saved-and-waiting matters: tell them their cart or booking survives the hiccup.
• No shame, no alarm. No red sirens, no exclamation points. Declines are routine; your interface should act like it.
• Never reveal fraud-logic details. If your risk system blocked the transaction, don’t explain which signal tripped it — that’s a manual for fraudsters. A neutral “This payment couldn’t be processed. Please try another payment method or contact support” protects the system while still giving a path forward.

System errors — timeouts, outages, failed saves — have their own golden rule: be honest about whose fault it is. Users waste enormous energy on “is it me or is it you?” Answer it explicitly. “Something went wrong on our end — your info is fine, please try again in a minute” is an apology; “check your connection and retry” is a diagnosis. Both are fine messages. What’s not fine is ambiguity that leaves someone re-entering a perfectly good credit card number three times because your server was the problem all along. If you offer a retry button, make it actually retry (preserving everything they entered), and if the retry is automatic, say so: “Reconnecting… we’ll keep trying for you.”

When is humor okay in an error message?

Gentle personality is lovely — in the right place. A playful 404 page, a cheeky empty state, a warm “well, that wasn’t supposed to happen” on a low-stakes glitch: these humanize your product and nobody gets hurt.

But humor must be calibrated to severity, and the line is simple: the more the user stands to lose, the more serious your tone gets. Never be funny about payments, data loss, security, or anything involving someone’s money, work, or identity. “Whoops! Your payment did a little oopsie 🙈” is a message written for the writer’s amusement, not the reader’s panic. The person staring at it is wondering if they were just charged twice. Meet that moment with calm, competent clarity — “Your card wasn’t charged. Here’s what to try next” — and save the jokes for the 404 page.

A quick severity ladder you can hand to your team: low stakes (404s, empty states, minor UI hiccups) — personality welcome; medium stakes (form validation, timeouts) — warm but straightforward; high stakes (payments, deletions, security, data loss) — calm, precise, zero whimsy. When in doubt, drop one rung more serious.

How do you write secure login errors without being useless?

Here’s a genuinely tricky one, and I want to be honest about the tradeoff instead of pretending it away. The helpful instinct says: tell people exactly which field was wrong. “That password doesn’t match this email” would be wonderfully clear. But confirming that an email does have an account — which that message does — enables what security folks call account enumeration: an attacker can feed in thousands of addresses and learn which ones are your customers, then target them with phishing or credential-stuffing attacks.

So login errors deliberately stay vague on which part failed: “That email and password combination doesn’t match our records.” It’s less helpful than it could be, and that’s a real cost, paid on purpose, for your users’ protection. The craft is to be vague about the diagnosis while being generous with the recovery:

• Offer the escape hatches right there: “Forgot your password?” and “Don’t have an account yet? Sign up” links directly under the error.
• Catch the fixable stuff you can mention safely: caps lock warnings, an obviously malformed email, a leading space from autofill.
• Keep the same discipline on password reset: “If that email has an account, we’ve sent a reset link” — same message whether the account exists or not.

The same balance applies anywhere an error could leak information — “that username is taken” on signup is a milder version of the same leak, and teams reasonably differ on where to draw that line. The point is to draw it consciously, not accidentally.

How do you make error messages accessible?

An error message nobody perceives is a dead end with extra steps. Three requirements, none optional:

• Announce errors to screen readers. A red message that silently appears in the visual layout is invisible to someone using assistive technology — the plain-language version: screen readers only speak changes you explicitly flag. Your developers do this with an “aria-live” region (for dynamic messages) or by associating the error text with its field, so the error is read aloud the moment it appears. Put it in your acceptance criteria, not your backlog.
• Never rely on color alone. A field that “turns red” communicates nothing to someone with red-green color blindness — and that’s a meaningful slice of your audience. Pair color with an icon, a text label, and a visible message. The test: screenshot your error state in grayscale. Can you still find the problem?
• Move focus sensibly. After a failed submit, keyboard and screen-reader users shouldn’t be stranded at the bottom of the page. Move focus to the error summary or the first failed field, so the next keystroke starts the fix. And don’t trap anyone — error modals need a working close button and Escape key.

Accessible error handling isn’t a separate, fancier version of good error handling. It’s the same three-part formula — what, why, how to fix — delivered so that everyone actually receives it.

How do you audit and measure your error messages?

You can’t rewrite what you’ve never seen. Most teams have no inventory of their own error states — errors are scattered across validation rules, API responses, and payment providers, and no one has ever read them all in one sitting. So build the inventory. Here’s the worksheet; a spreadsheet with six columns is plenty.

The error-audit worksheet:

• Column 1 — Location: where the error appears (signup form, checkout step 2, login, password reset, contact form, in-app save…).
• Column 2 — Trigger: how you made it fire. This is the fun part: spend an afternoon deliberately breaking your own product. Submit empty forms. Type malformed emails. Use an expired test card. Kill your wifi mid-save. Paste emoji into the phone field. Trigger every error you can find.
• Column 3 — Exact current text: copied verbatim, then read cold — as if you’re a stressed stranger seeing it for the first time. (Reading your errors out loud to a teammate is humbling and I highly recommend it.)
• Column 4 — Three-part test: does it say what happened, a useful why, and how to fix it? Pass/fail each part.
• Column 5 — Conduct check: does it blame the user? Does it preserve their input? Is the tone matched to the severity? Is it accessible (announced, not color-only, focus handled)?
• Column 6 — Rewrite: your new text, built from the template below.

The three-part rewrite template — fill in the brackets and you’re most of the way there:

• “[What happened, plainly]. [Why, only if it helps them]. [Exactly what to do next — and reassurance that their work/order/data is safe].”
• Example: “We couldn’t send your message. The connection dropped for a moment — everything you wrote is still here. Please try again, or email us directly at the address below.”

Then measure two things, against your own baselines rather than anyone else’s benchmarks:

• Error frequency. How often does each error fire? Your most frequent errors are your biggest opportunities — and remember, the best error message is the one that never appears. Before polishing the copy, ask whether the cause is fixable: a confusing field, a needless format rule, a missing hint. Fix the cause first; rewrite what remains.
• Recovery rate. Of the people who see a given error, how many go on to complete the task? Track it before and after your rewrite. That trend line — yours, in your product, with your audience — is the only error-message statistic worth acting on.

A small note from my world: this applies beyond your website. If you manage social media, your scheduling tool’s errors matter too — a vague “post failed” at 6am with no reason and no retry can quietly cost you a week of content. At SocialBlaze we sweat this stuff: when a connected account needs re-authorizing or a network rejects a post, the goal is always to tell you plainly what happened and exactly how to fix it, with your drafted content kept safe. Judge any tool you use — ours included — by how it treats you when something goes wrong.

Frequently asked questions

What are the three parts of a good error message?

What happened in plain words, why it happened (only when the reason helps the person), and exactly how to fix it. Every error message in your product should be judged against those three parts — and against two conduct rules: never blame the user, and never wipe their input.

Should error messages appear while someone is still typing?

Generally no. Validate on blur (when someone leaves a field) or on submit, because flagging an incomplete entry mid-keystroke feels like being scolded for thinking. The exception: once a field has shown an error, switch to live validation so the error clears instantly when it’s fixed.

Why don’t login errors say whether the email or the password was wrong?

Because confirming that an email has an account enables account enumeration — attackers can test thousands of addresses to learn who your users are, then target them. The deliberately vague “email and password don’t match” trades a little helpfulness for real protection, so compensate with generous recovery paths like a prominent password-reset link.

Is it okay to make error messages funny?

Only when the stakes are low. A playful 404 page or empty state is charming; humor on payment failures, data loss, or security issues reads as flippant to someone who’s genuinely worried. Calibrate tone to severity, and when in doubt, be one notch more serious.

How do I find all the error messages in my product?

Run an error-state inventory: spend an afternoon deliberately triggering every error you can — empty submits, bad formats, declined test cards, dropped connections — and log each one’s location, trigger, and exact text in a spreadsheet. Then read each message cold, score it against the three-part formula, and rewrite the failures.