HTML Password Input Field
An HTML password field uses type="password". The browser masks the characters visually while the user types, but the entered value is still submitted with the form just like other form data.
<label for="pwd">Password</label>
<input type="password" id="pwd" name="password" autocomplete="current-password">Basic Password Field Example Top ↑
A password input is similar to a text input, but the browser obscures the characters visually.
<form method="post">
<label for="user-password">Password</label>
<input type="password" id="user-password" name="password" required>
<button type="submit">Sign in</button>
</form>The browser may display dots, bullets or another masking symbol depending on the browser and operating system. Do not rely on a particular symbol such as an asterisk.
name and id Top ↑
The id connects the password field to its label and can also be used by JavaScript or CSS. The name is the key used when the value is submitted with the form.
<label for="account-password">Password</label>
<input type="password" id="account-password" name="password">A form control generally needs a name if its value should be included in form submission.
Autocomplete for Password Fields Top ↑
Use the appropriate autocomplete value so browsers and password managers understand the field's purpose.
<!-- Existing password during sign-in -->
<input type="password" name="password" autocomplete="current-password">
<!-- Password being created or changed -->
<input type="password" name="new_password" autocomplete="new-password">Do not disable password-manager support merely to force users to type passwords manually.
minlength, maxlength and pattern Top ↑
HTML can provide useful browser-side constraints, but browser validation never replaces server-side validation.
<label for="new-password">Create password</label>
<input type="password"
id="new-password"
name="new_password"
minlength="12"
maxlength="128"
autocomplete="new-password"
required>The pattern attribute can enforce a format when a specific rule is genuinely required, but avoid unnecessarily restrictive password rules that prevent users from choosing long passphrases or password-manager-generated passwords.
Why Default Password Values Should Usually Be Avoided Top ↑
The original page used a password field with value="pwd". Although the value attribute is valid, pre-filling a real password in HTML source is normally a bad practice because page source and developer tools can reveal it.
<!-- Avoid pre-filling real passwords like this -->
<input type="password" name="password" value="secret123">Show or Hide Password Top ↑
A show-password control can help users confirm what they typed. The control should be clearly labeled and should not remove the password field's normal form semantics.
<label for="login-password">Password</label>
<input type="password" id="login-password" name="password">
<button type="button" id="toggle-password" aria-pressed="false">Show password</button>JavaScript can switch the input's type between password and text. If you add this feature, keep the button state and accessible label synchronized with the visible state.
Security and Server-Side Handling Top ↑
- Masking is not encryption. Use HTTPS so credentials are encrypted in transit.
- Validate submitted data on the server even when HTML attributes such as
requiredorminlengthare present. - Do not place real passwords in HTML source, hidden fields, URLs or logs.
- Password handling on the server should use a modern password-hashing function rather than storing plaintext passwords.
- Use
method="post"for credential submission so the password is not placed in the URL query string.
Accessibility Top ↑
- Always provide a visible
<label>for the password field. - Do not use placeholder text as the only label.
- If password requirements exist, explain them before or near the field.
- Associate validation messages with the field when reporting errors.
- Use
autocomplete="current-password"orautocomplete="new-password"so password managers can assist users.
Common Password Field Mistakes Top ↑
Assuming masked text is secure Top ↑
The masking only hides characters from casual viewing on screen. It does not encrypt or securely store the submitted password.
Using GET for passwords Top ↑
GET places form values in the URL. Credential forms should normally use POST over HTTPS.
Pre-filling a real password with value Top ↑
Values embedded in HTML can be inspected. Avoid putting real passwords in page source.
Using placeholder instead of label Top ↑
Placeholders disappear as users type and are not a substitute for persistent form labels.
Trusting browser validation alone Top ↑
Client-side validation improves UX but can be bypassed. Validate and enforce requirements on the server.
Related Tutorials Top ↑
Frequently Asked Questions Top ↑
It creates a text-entry control whose characters are visually masked while the user types.
No. The field only masks the characters on screen. Use HTTPS to protect credentials in transit and secure server-side password handling after submission.
The id connects the field to labels, CSS or JavaScript. The name identifies the value when the form is submitted.
Use autocomplete="current-password" for an existing password and autocomplete="new-password" when the user is creating or changing a password.
Normally no. Real passwords should not be embedded in HTML source where they can be inspected.
No. Browser-side constraints improve usability, but the server must still validate and enforce password requirements.
HTML Form Hidden field Text field
Subhendu Mohapatra
Author & Instructor at plus2net
I write and maintain practical tutorials on Python, PHP, SQL, JavaScript, HTML, jQuery, and web development at plus2net. The tutorials focus on clear explanations, working examples, and code that readers can test and adapt while learning.
