How to check your website's forms: labels, input types, HTTPS and CSRF

Contact forms, sign-ups, logins, checkouts and search boxes are where your site asks visitors to do something. A form that's confusing, hard to fill in on a phone or insecure costs you leads and trust — and form problems rarely show up until someone complains, because the people who give up don't tell you.

Most form problems are visible in the HTML, so they can be checked without filling anything in. Here's what to look at.

Usability and accessibility

Every field needs a label

Each input needs a <label> linked to it with for and id (or wrapping it). Screen readers announce the label, and clicking it focuses the field. A placeholder is not a label: it disappears as soon as someone types, often has low contrast, and isn't reliably announced. If a design truly can't show a visible label, aria-label is the fallback, but visible labels help everyone. Our accessibility guide covers labels in more depth.

Use the right input type

type="email", type="tel" and type="url" bring up the right keyboard on phones and give basic browser validation. A phone field with type="text" makes mobile visitors hunt for digits. Be careful with type="number": it's meant for quantities, not phone numbers, card numbers or postcodes.

Add autocomplete hints

The autocomplete attribute tells browsers and password managers what each field is: name, email, tel, street-address, postal-code, cc-number, current-password, new-password, one-time-code. It lets visitors fill a form in one tap and is a WCAG 2.1 requirement (success criterion 1.3.5) for fields that collect information about the user. Don't put autocomplete="off" on password fields: it pushes people towards weaker, reused passwords.

A real submit button, and helpful validation

Use a <button type="submit"> so the form works with the Enter key and without custom JavaScript. Mark required fields with the required attribute and say so in the label, and show error messages next to the field in plain words. Adding novalidate switches off the browser's built-in checks; that's fine only if you replace them with your own.

Security

• HTTPS for the page and the action. A password field on an HTTP page, or a form whose action points to an http:// URL, sends what people type in plain text. Both page and action must be HTTPS.
• Never GET for passwords. With method="get", form values go into the URL — and from there into browser history, server logs and referrer headers. Use method="post" for anything sensitive.
• CSRF protection. Forms that change something (log in, update an account, place an order) should be protected against cross-site request forgery, usually with a secret token in a hidden field that the server checks, plus SameSite cookies. See how to check cookie security.
• Know where data goes. A form that submits to another domain, such as a mailing-list or CRM provider, may be expected — but make sure it's intentional and covered by your privacy policy.
• Validate on the server. Browser validation is a convenience for honest visitors; anyone can bypass it. The server must check every value again.

How Rudra checks forms — without submitting them

The free broken link checker and the website audit load your page in a real browser and review up to 10 forms on it. They flag, with the form and field names involved:

• password fields on an HTTP page, forms submitting to http://, and password forms using GET (each costs 10 points);
• fields whose only label is a placeholder (3 points);
• fields with no accessible label, input types that don't match the field (an email field using type="text"), missing autocomplete hints, autocomplete="off" on passwords, forms submitting to another host, forms with no submit button, required email or phone fields without constraints, and novalidate — all informational;
• POST forms with no visible CSRF-style token — at low confidence, because the token may be added by JavaScript or the server may protect the form another way.

It also asks the browser, once, whether it would block an empty submission of fields marked as required — by reading each field's validation state, without focusing or filling anything, and without triggering the site's own validation handlers.

Why we never submit forms

Submitting a form has real effects: an email lands in someone's inbox, an account gets created, an order or a support ticket appears, a rate limit or fraud filter trips. An automated tool has no way to know which forms are safe to send, so ours sends none. Forms are never submitted, clicked, focused or filled, and reports contain field names and labels only — never values.

The trade-off is that some things can only be tested by sending a form, and those are up to you: whether the submission arrives, what the confirmation and error messages look like, whether the server rejects bad or cross-site input, and whether spam protection works.

A manual test for each form

1. Fill it in on a phone and check that each field brings up the right keyboard and autofills sensibly.
2. Complete it using only the keyboard, then with a screen reader such as NVDA or VoiceOver.
3. Submit it empty and with a wrong email address, and read the error messages.
4. Submit it properly and confirm the message arrives where it should.
5. For logins and account forms, ask a developer to confirm CSRF protection and server-side validation.