Inline examples belong in help text, not field labels

Labels name the field

A field label tells users what information belongs in that input. "Phone number" identifies the field. "Email address" identifies the field. "Billing ZIP code" identifies the field.

The label answers what goes here, not how should I format it.

Help text demonstrates format

If you need to show users a formatting example, put it in help text below the field. "555-123-4567" demonstrates phone format. "you@example.com" demonstrates email format. "12345 or 12345-6789" demonstrates ZIP code options.

Help text sits visually separate from the label. Screen readers announce it after the label but before the user starts typing. Users can ignore it if they already know the format.

What breaks when you combine them

When you write "Phone number (555-123-4567)" as your label, you've created three problems.

First, screen reader users hear the example every time they navigate to that field. The label becomes verbose noise instead of a quick identifier.

Second, you've made the label harder to scan visually. Users looking for "phone" have to parse through parentheses and numbers.

Third, you're now maintaining format examples inside every label string instead of in one reusable help text component. When you need to change the example format, you'll hunt through labels instead of updating help text templates.

When format matters enough to show

Most fields don't need format examples. Users know how to type their name or email address. They've filled out city fields before.

Show format only when:

• Multiple valid formats exist and you accept only one
• The field uses uncommon structure (employee ID, account number)
• Formatting is strict and errors are likely (international phone numbers, specific date formats)

If you can accept multiple formats and parse them on the backend, do that instead of showing format rules.

Where help text lives

Help text goes directly below the field, before any validation messages. It uses smaller, secondary-styled text. It stays visible while users type.

Some forms hide help text until users focus the field. That's acceptable for progressive disclosure, but the label must still work alone. Don't write "Format" as your label and hide the actual format instruction until focus.

Labels that do double duty fail at both

You might see "Email (we'll send your receipt here)" trying to serve as both label and purpose explanation. Split it. Label: "Email address." Help text: "We'll send your receipt to this address."

Or "Password (8+ characters, one number)" trying to be label and requirement. Label: "Password." Help text: "Must be at least 8 characters and include one number."

Each element has a job. When you combine them, both jobs get harder to do.

Test without the parentheses

If you've written a label with parentheses, read it without them. If what remains is a complete, useful label, move the parenthetical content to help text. If what remains doesn't identify the field clearly, rewrite the label.

"Email (required)" becomes label "Email address" plus an asterisk or required indicator. "Address (shipping)" becomes label "Shipping address" with no help text needed.

Parentheses in labels almost always signal content that belongs somewhere else.

Format before fields

Before you add help text to individual fields, look at your form structure. If every field needs format instructions, your form sections need clearer labels or your fields need better defaults.

Help text patches individual field confusion. Section labels prevent it.