<input type="password"> masks each character as it's typed — but it's important to understand exactly what that does and doesn't protect.
Syntax
<input type="password" name="password" minlength="8" required>Basic Example
<label for="password">Password</label>
<input type="password" id="password" name="password" minlength="8" required autocomplete="new-password">Browser output: each typed character appears as a dot or asterisk instead of the actual letter — purely a local, visual privacy measure against someone glancing at the screen.
How It Works
type="password" only masks the value visually in the browser. It does not encrypt the data, and it does not protect it in transit — that's what HTTPS is for. The masking is a screen-privacy feature, not a security feature by itself.
Important Attributes
| Attribute | Purpose |
|---|---|
minlength | Minimum required character count |
autocomplete | current-password for login forms, new-password for signup/change-password forms — see autocomplete |
Real-World Example
<label for="login-password">Password</label>
<input type="password" id="login-password" name="password" autocomplete="current-password" required>A login form's password field — autocomplete="current-password" tells the browser's password manager this is an existing password to fill in, not a new one to suggest.
Common Mistakes
- Believing
type="password"alone makes a form "secure" — without HTTPS, the actual password is still sent in plain text over the network - Skipping server-side password hashing because the field "already masks it" — masking is purely visual and has nothing to do with how the value is stored or transmitted
- Using
autocomplete="off"to block password managers — this actually hurts security by discouraging strong, unique, manager-generated passwords
Best Practices
- Always serve any page with a password field over HTTPS
- Set the correct
autocompletevalue rather than disabling it - Hash passwords server-side — never store or compare them in plain text
Accessibility Considerations
Consider a visible "show password" toggle (implemented with JavaScript, toggling the input's type between password and text) — this genuinely helps users prone to typos, including many users with motor or cognitive differences.
SEO Considerations
No direct ranking effect, though HTTPS itself (needed to actually protect password fields) is a confirmed, if minor, ranking factor.
Browser & Modern HTML Notes
Browsers increasingly warn users (sometimes blocking autofill or showing "Not Secure" in the address bar) when a password field is served over plain HTTP instead of HTTPS.
Mini Practice
- Build a signup password field with
autocomplete="new-password"and aminlength. - Explain, in your own words, why masking characters is not the same as encrypting them.
