Learning objectives
Select text-like input types by purpose; provide autocomplete tokens; distinguish keyboard hints from validation rules.
Prerequisites
Complete the forms lesson and understand label, id, name, required, and form submission.
Start with the kind of information
Text is the general single-line input. Search represents a search query and may receive browser-specific search controls. Email and URL add syntax-related validity rules. Tel describes a telephone number but does not enforce a universal telephone format. Password masks the visible characters; it does not encrypt the value or prevent scripts on the page from reading it.
Choose the input type from the information’s meaning rather than from the keyboard you want. A postal code, account identifier, or credit-card number is usually text, even when it contains digits. These values may contain leading zeros and are not quantities to increment with a number spinner. The inputmode attribute supplies a keyboard hint without changing the underlying data type.
Help the browser help the learner
Autocomplete tokens describe the expected value, such as name, email, tel, username, current-password, and new-password. They help browsers and password managers populate fields consistently. A label describes the control to the person; an autocomplete token describes it to autofill software. They solve different problems and should agree.
Use maxlength when a real storage or product limit exists, and communicate the limit visibly. Minlength is useful only when there is a meaningful lower bound. Avoid rules that reject ordinary real-world names because they contain spaces, apostrophes, hyphens, accents, or writing systems you did not anticipate. Validation should protect a genuine requirement rather than enforce one author’s assumptions about everyone’s data.
Placeholder text may provide a short example, but it disappears during typing and often has weaker contrast. Keep the label and essential instructions visible. If a field is optional, say so where the user can discover it before submitting. Do not collect an alternate contact method unless the workflow needs it.
Separate format checks from verification
A syntactically valid email can still be undeliverable or belong to someone else. A URL can point to an unreachable or unsafe destination. A telephone field can contain a number that the business cannot call. Browser checks reduce accidental mistakes but do not establish ownership, trust, or authorization.
For a password field, allow password-manager use and avoid disabling paste. The receiving application must use HTTPS, appropriate credential handling, and server validation. This lesson’s playground does not send values to a server, so use invented examples only and never paste a real password into a learning exercise.
Working example
<form>
<label for="contact-email">Email address</label>
<input id="contact-email" name="email" type="email" autocomplete="email" required>
<label for="contact-phone">Telephone (optional)</label>
<input id="contact-phone" name="phone" type="tel" autocomplete="tel">
<button type="submit">Check details</button>
</form>Another example
<label for="postal">Postal code</label>
<input id="postal" name="postal" type="text" inputmode="numeric" autocomplete="postal-code">
<label for="account-password">Password</label>
<input id="account-password" name="password" type="password" autocomplete="current-password">Expected output
The first form offers email syntax checking and an optional telephone control. Native keyboard and clear-button details vary by browser. Submission is blocked in the isolated playground; it only demonstrates control behavior.
Common mistakes
Do not use type=number for a phone number or postal code. Do not assume tel validates a number, password encrypts a value, or autocomplete=off guarantees password managers will ignore a field. Avoid a pattern that accepts only one country’s format unless the service explicitly requires it.
Accessibility and browser notes
Use visible labels and clear optional-field wording. Keep the label text in the accessible name so voice-control users can refer to what they see. Mobile keyboard hints are suggestions; hardware keyboards and assistive input tools may behave differently.
Practice
Create a search field and a personal website field. Make the search required, and let the website remain optional.
Review the solution and reasoning
<label for="catalogue-query">Search the catalogue</label>
<input id="catalogue-query" name="q" type="search" required>
<label for="website">Website (optional)</label>
<input id="website" name="website" type="url" autocomplete="url">The search type communicates a query without imposing email or URL syntax. The website field asks for a URL, but omitting required permits an empty value. A real application still decides which URL schemes and destinations it accepts.