Text Field

Signing up for a food delivery app, searching for a flight, typing a card number, leaving a note for the courier: almost every journey in an app goes through a text fieldText fieldAn input where the user types text, like a name, email, password or search query.Open in glossary →. It’s the most common input on the planet, and because users can type anything into it, it’s also one of the richest places to find bugs.

In this lesson you’ll learn what a good text field looks like on each platform, and how testers break the bad ones. For whole forms (validation timing, error summaries, server errors and real-world data), see Forms and Validation.

What is a text field?

A text field is a box that accepts free text from the keyboard. It can be a single line (name, email, promo code) or several lines (a review, delivery instructions). Unlike a dropdown or a toggle, the user isn’t choosing from options: they can enter any character, in any amount, in any language. That freedom is exactly what makes it risky.

You’ll usually see text fields used for:

• Personal data: name, email, phone number, address.
• Secrets: passwords, PINs, one-time codes.
• Search: products, recipes, destinations.
• Free-form content: reviews, chat messages, notes for the courier.
• Numbers that aren’t really “numbers”: postcode, card number, quantity, amount.

Anatomy

How it differs from similar components

Component	What the user does	Typical use
Text field	Types a short, single line	Name, email, promo code
Text area (multiline field)	Types several lines	Reviews, messages, delivery notes
Search field	Types to find something, usually with instant results	Product search, filtering a list
Dropdown / select	Picks one value from a fixed list	Country, size, sort order
Combo box	Types to filter a list, then picks	Choosing a city from thousands
Date picker	Picks a date from a calendar or wheel	Birthday, booking dates

Dev note

iOS calls it a text field (UITextField, or TextField in SwiftUI) and a text view for multiline. Android developers say EditText, while Material Design says text field. On the web it’s an <input> element (or <textarea> for multiline). In bug reports, use the name your team uses.

Designs & variants

Each platform has its own look. The parts are the same, but the risks differ: a floating label can overlap autofilled text, a left-hand label can truncate, a field with no visible label can confuse everyone.

Every field below is live: click, type, clear, and tab through them. Use the switch to compare light and dark.

Dark

Delivery address

Name

Street

Postcode

First name

As shown on your ID

Email

Email address *

We'll send your order updates here.

Password

At least 8 characters

Search

Delivery instructions

Ring twice, the bell is broken 🔔

32/80

Country

Can't be changed after ordering.

Postcode

A postcode has 5 digits, like 10000.

Types and mobile keyboards

On a phone, the field’s type decides which keyboard appears. A missing or wrong type is a real, reportable bug: imagine typing an email on a keyboard with no @ key, or a postcode on a full letter keyboard.

⌨️ One field, many keyboards

On a phone, the input type decides which keyboard opens. Pick a field type and see what the user gets.

EmailNumberAmountPhonePasswordWebsite

Email

@gmail.com|@icloud.com

qwertyuiop

asdfghjkl

zxcvbnm

123space@.return

Web (HTML)

type="email" autocomplete="email"

iOS keyboard type

.emailAddress, autocapitalization off

Android inputType

textEmailAddress

What to check

The @ and . keys are visible, the first letter is NOT capitalized, and autocorrect does not "fix" the address.

States

A text field goes through several UI statesUI stateHow a component looks and behaves in a given situation: default, hover, pressed, focused, disabled, loading, error.Open in glossary →. Each one needs to look different and behave correctly.

State	What it looks like	What to check
Empty	Label and maybe a placeholder	The placeholder is an example, not the only label
Focused	Highlighted border, cursor blinking, keyboard open	Focus is clearly visible (not only a color change)
Filled	Shows the value	Long values scroll or wrap; nothing is cut off on save
Disabled	Dimmed, can’t be focused	Can’t be edited by tapping, Tab key, or autofill. See disabled stateDisabled stateA component that is visible but can't be used right now, usually shown greyed out.Open in glossary →
Read-only	Looks like text, can be selected and copied	Can’t be changed, but CAN be copied and read by screen readers
Error	Red border and a message	The message explains how to fix it, and disappears once fixed
Loading	Small spinner, e.g. “Checking username…”	Typing fast doesn’t show the result for an old value

When should errors appear?

Input validationInput validationChecking that what the user typed is acceptable before the app uses it.Open in glossary → checks the value. The tricky part is timing. Show the error too early and you nag the user mid-sentence; show it too late and they discover all problems at the end. Try the three common strategies:

⏱️ When should the error appear?

Pick a strategy, then type an address slowly, e.g. "anna@test.com". Try leaving the field half-done, too.

While typingOn blurOn submit

Sign in to FreshCart

We'll email you a one-time code.

Email

Continue

0

times an error popped up while typing

—

no error shown

On blur

No error until you leave the field. After that, the field re-checks as you type, so the error disappears the moment the value is fixed. This "late to complain, quick to forgive" approach is the usual recommendation.

Start again

Autofill and autocomplete

Phones and browsers can fill in names, addresses, passwords and one-time codes for the user. It only works if each field tells the system what it contains.

Field	Web autocomplete	iOS textContentType	Android autofillHints
Full name	name	.name	personName
Email	email	.emailAddress	emailAddress
Phone	tel	.telephoneNumber	phone
Street address	street-address	.fullStreetAddress	postalAddress
Postcode	postal-code	.postalCode	postalCode
New password	new-password	.newPassword	newPassword
SMS code	one-time-code	.oneTimeCode	smsOTPCode

When testing autofill, check that values land in the right fields (no surname in the city field), that autofilled values pass validation (autofill sometimes adds a trailing space), and that floating labels don’t overlap the filled text.

When to use it

A text field is the right choice when:

• The answer is truly open: names, addresses, messages, search terms.
• There are too many possible values to list (every email address in the world).
• Users know the answer and typing is faster than scrolling (a postcode, a promo code).

Good and bad uses

Common bugs

These are the text field bugs testers report again and again.

#	Bug	What you see	Typical severity
1	Spaces break validation	A valid email with a trailing space (from autofill or copy-paste) is rejected	High
2	Error never clears	You fix the value, but the red message stays until you submit again	Medium
3	Silent truncation	A phone number or address is cut off at a hidden limit, with no message	High
4	Wrong character count	The counter says “2/20” for one emoji, or a limit cuts an emoji in half	Low–Medium
5	“Numeric” field accepts letters	A postcode, quantity or year accepts 19ab and saves it	Medium
6	Wrong keyboard	Email opens a keyboard with no @; a postcode opens letters	Medium
7	Valid input rejected	O'Brien, Đurđa, anna+shop@test.com or a 2-letter surname is refused	High
8	Input rendered as HTML	Typing <b>Anna</b> shows Anna in bold somewhere. A sign of an XSSCross-site scripting (XSS)An attack where text a user enters is run as code in other people's browsers.Open in glossary → hole	Critical
9	Broken characters	Kovač is saved or shown as KovaÄ or Kova? (an encoding bug)	Medium–High
10	Paste blocked	Paste does nothing in password or “confirm email” fields	Medium
11	Data lost	Text disappears after rotating, switching apps, or a failed submit	High
12	Keyboard hides the field	The field (or its error) is behind the on-screen keyboard and can’t be seen	Medium

Stress-test it

This is where testers earn their money. Real users paste, autofill, use emoji and have names developers never imagined. Each input below is a classic negative testNegative testingTesting with invalid or unexpected input to check the software handles it gracefully.Open in glossary → or edge caseEdge caseAn unusual situation at the extreme of what the software should handle.Open in glossary →:

🧪 Input torture playground

Testers feed fields the inputs developers forget. Pick a test input (it is pasted into the field) or type your own, and see how a well-built field handles it.

Full name fieldEmail field

EmptySpaces onlyVery longEmoji 👩‍💻č ć ž đ šCyrillicLeading / trailing spacesO'BrienHyphen & plusMiXeD CaSe<b>html</b>SQL-likePasted with newline

Checkout details

Full name

Preview on next screen

Nothing valid to show yet

Typed / pasted

(nothing)

Length

0 characters

Result

Waiting for input…

Why testers try this

Pick a test input above. Each one targets a different kind of bug.

Find the bug

The plant shop sign-up below has six bugs. Test it like a pro:

• Type valid data first, then invalid data.
• Leave fields half-done and come back to fix them.
• Use emoji, spaces and international formats.
• Watch the keyboard, the profile preview and the network log.

🐞 Bug hunt: Bloom sign-up

This demo has 6 hidden bugs. Explore it like a tester, then check your findings.

Found0/6

9:41

Create account

Profile preview

Hi, there!

Display name0/30

Email

Phone

Year of birth

Password

Create account

Tip: the keyboard shows which type each field opens.

Restart app

Network log

Create an account to see the request body…

1. 1

   Hint: Leave the email field with a typo, then go back and fix it.

   Email error does not clear after fixing the value

   The error is checked when you leave the field, but only cleared when you press Create account. After fixing anna@test to anna@test.com the red message still says the email is invalid. Expected: the error disappears as soon as the value is valid.

   Reveal answer✓ I found this
2. 2

   Hint: Keyboards and autofill often add a space after the last word.

   A trailing space makes a valid email invalid

   anna@test.com (with a space at the end) is rejected, even on submit. The app validates the raw value without trimming it. Expected: leading and trailing spaces are removed before validating and saving.

   Reveal answer✓ I found this
3. 3

   Hint: Put emoji in the display name and watch the counter.

   Character counter counts emoji wrongly

   The counter uses the string length in code units: one 🌸 counts as 2, and 👩‍💻 counts as 5, so users hit the 30-character limit long before 30 visible characters. Expected: the counter counts characters the way people see them.

   Reveal answer✓ I found this
4. 4

   Hint: Type the phone number in the format shown in the placeholder.

   Phone number is cut off silently

   The field stops accepting input after 10 characters, so +385 91 234 5678 becomes +385 91 23 with no message, and the cut number is sent to the server (see the network log). Expected: international numbers fit, or a clear message explains the limit.

   Reveal answer✓ I found this
5. 5

   Hint: Look at the keyboard for Year of birth, then try typing letters.

   Year of birth accepts letters and opens the wrong keyboard

   The field opens the full letter keyboard and accepts values like 19ab or 3000; the account is created with that value. Expected: a number pad (inputmode="numeric") and validation that only allows realistic 4-digit years.

   Reveal answer✓ I found this
6. 6

   Hint: Type a display name like <b>Anna</b> and watch the profile preview.

   Display name is rendered as HTML in the profile card (XSS)

   The preview shows Anna in bold instead of the literal text <b>Anna</b>. With <img src=x onerror=alert(1)> a script runs (simulated here). Expected: user input is always shown as plain text. Severity: critical.

   Reveal answer✓ I found this

How to test it

Checklist

Text field test checklist

0 of 14 checked

Copy

• Every field has a visible label that stays visible while typing
• The right keyboard opens for each type (email, number, phone, password, URL)
• Required fields reject empty and spaces-only values with a clear message
• Leading and trailing spaces are trimmed before validation and saving
• Minimum, maximum and maximum + 1 characters behave as specified, with no silent truncation
• Emoji, accented letters (č ć ž đ š), Cyrillic and apostrophes are accepted and shown correctly after saving
• HTML tags and quotes are shown as plain text everywhere the value appears
• Error messages appear at the agreed time, explain how to fix the problem, and clear once fixed
• Copy, paste, undo and autofill work (including in password fields)
• Password show/hide toggles both ways without losing the value
• Entered text survives rotation, backgrounding the app and a failed submit
• The focused field and its error are not hidden behind the keyboard
• Screen readers announce the label, value, hint and error message
• Fields work at the largest text size and in dark mode

Example test cases

Accessibility

Text fields are where many users with disabilities get stuck. Check these:

• A real label. Every field needs a label connected to it in code. A placeholder doesn’t count. Test it: tapping the label on the web should focus the field.
  Dev note

  <label for> on the web, accessibilityLabel on iOS, labelFor or a Material label on Android.
• Screen readers (VoiceOver / TalkBackScreen readerSoftware that reads the screen aloud for blind and low-vision users, like VoiceOver or TalkBack.Open in glossary →) should announce the label, the field type (“text field”, “secure text field”), the current value, any hint and the error message.
  Dev note

  On the web, errors are linked with aria-describedby and marked with aria-invalid="true".
• Errors aren’t color only. A red border isn’t enough: there must be text, ideally with an icon.
• Contrast: text, label and placeholder need at least 4.5:1 against the background; the field’s border at least 3:1 (WCAGWCAGThe Web Content Accessibility Guidelines, the main international standard for accessibility.Open in glossary →).
• Big text: at the largest Dynamic TypeDynamic TypeThe phone setting that lets users make text bigger or smaller across apps.Open in glossary → sizes, labels and values must stay readable, not clipped.
• Touch targetsTouch targetThe area of the screen that responds to a tap, which should be large enough for a finger.Open in glossary →: the field and its icon buttons (clear, show password) should be at least 44×44 pt on iOS and 48×48 dp on Android. On the web, WCAG 2.5.8 (AA) asks for at least 24×24 CSS px; 44×44 px (2.5.5, AAA) is the comfortable target.
• Autocomplete attributes help users with motor or memory difficulties fill forms without typing. On the web that’s a WCAG requirement for fields about the user, too (1.3.5 Identify Input Purpose, Level AA).

Mobile vs web

iOSAndroidWeb

Dev note

Native components: UITextField / UITextView (UIKit), TextField / TextEditor (SwiftUI).

• Keyboard type, auto-capitalization, autocorrect and the autofill content type are set per field. Check all four.
  Dev note

  The autofill content type is textContentType.
• Clear button (“x”) and secure entry (dots) are built in.
• The keyboard can cover the field: scroll the form and check the focused field is visible.
• Test Dynamic Type, dark mode and the Passwords autofill bar.

Dev note

Native component: EditText; with Material Design, TextInputLayout (filled or outlined) or TextField in Jetpack Compose.

• Test the keyboard with Gboard and Samsung Keyboard, because they behave differently.
  Dev note

  The inputType controls the keyboard.
• Floating labels: check they don’t overlap autofilled text or the prefix/suffix.
• Check what happens after rotation and after the app is killed in the background: the text should survive.
• Test with font scale, display size and TalkBack.

Dev note

HTML <input> with a type (email, tel, password, number, url, search) or <textarea>.

• type="number" has quirks (it accepts e, and in Chromium browsers the mouse wheel changes a focused value; see Stepper), so many teams use inputmode="numeric" instead. Know which one your app uses.
• Use DevTools to check the label, autocomplete, aria-invalid and aria-describedby attributes.
• Test browser autofill in Chrome, Safari and Firefox, plus password managers.
• Test on a phone browser too: the right keyboard depends on type and inputmode.

Check your understanding

Quick quiz

0/5 answered · 0 correct

1. 1.Why is a placeholder NOT a replacement for a label?

   APlaceholders are not supported on AndroidBIt disappears as soon as the user types, and is often low-contrast and skipped by screen readersCPlaceholders make the field slowerDLabels are only needed for passwords

2. 2.A valid email with a trailing space is rejected. What is the most likely cause?

   AThe server is downBThe value is validated without trimming whitespaceCThe keyboard type is wrongDThe email is too long

3. 3.The quantity field shows a number pad. Do you still need to test letters?

   ANo, the keyboard makes letters impossibleBYes, because users can paste, autofill or use a hardware keyboardCOnly on AndroidDOnly if the requirements say so

4. 4.You type <b>Anna</b> as your name and the confirmation screen shows "Anna" in bold. How serious is this?

   ACosmetic, low severityBMedium: the name looks oddCCritical: user input is rendered as HTML, which allows XSS attacksDNot a bug: bold names look nice

5. 5.Which validation timing is generally recommended for an email field?

   AShow an error after the very first characterBValidate when the user leaves the field, then re-check live as they fix itCNever show errorsDOnly validate on the server, days later

Key takeaways

• A text field accepts anything, so test far beyond the happy path: empty, spaces, long, emoji, accented letters, apostrophes, HTML and pasted text.
• Every field needs a visible label. A placeholder is an example, not a label.
• The input type decides the mobile keyboard and autofill, but it’s not validation.
• Errors should appear at a sensible time, explain how to fix the value, and disappear once it’s fixed.
• The classic bugs: untrimmed spaces, stale errors, silent truncation, wrong counts with emoji, wrong keyboards, valid names rejected, and input rendered as HTML.