Form Field Validator

Paste a form submission and validate every named field at once — email, phone, URL, postal code, credit card, required fields, and country-specific format hints. Runs locally with no lookup services.

Try:
Validation report

About this tool

Use this form field validator when you need a quick, offline check of a whole submitted form rather than one value at a time. Paste name: value lines (or a JSON object), choose a country, mark required fields, and get a per-field report for common input types: email, phone, URL, postal code, credit card, and plain text.

Field types are inferred from names such as email, phone, zip, postal_code, website, card, and cc_number. Add rules like zip: postal-code or support_url: url when a field name is ambiguous. Country selection controls postal-code patterns and phone calling-code / national-length checks. The tool can normalize passing values and masks credit-card numbers by default.

This is a deterministic format validator. It does not perform DNS or MX checks, phone carrier lookups, address-existence checks, or BIN/issuer lookups. A passing result means the value is well formed for the selected rule; it does not prove the mailbox, phone number, address, or card account exists.

Worked examples

Validate a US signup form:

fields:
email: [email protected]
phone: (415) 555-2671
zip: 90210
website: https://example.com
card: 4111 1111 1111 1111

country: US
required: email, phone, zip
rules:
zip: postal-code
card: credit-card

The report starts with VALID when every required and typed field passes, shows normalized forms such as a lower-cased email domain and an E.164-style phone number, and masks card digits except the last four.

Find every issue in a broken form:

fields:
email: john@
phone: 555-12
zip: 9021

country: US
required: email, phone, zip, website
rules: zip: postal-code

The output lists each failing field with the reason, expected format, and an example for the selected country.

Supported checks and limits

FAQ

Does a valid email result mean the mailbox can receive mail?

No. This checks offline email syntax: one @, legal local/domain characters, label lengths, and a plausible alphabetic top-level domain. It does not query DNS, MX records, disposable-domain lists, or SMTP servers.

How are phone numbers validated?

With country = any, the phone check uses a generic E.164-style digit window. With a country code such as US, GB, or DE, it checks the calling code, accepted national digit length, and common trunk prefix handling. It is not a carrier-grade phone-number database or line-type lookup.

Can I validate postal codes for every country?

The tool includes a practical table of common postal-code formats for 38 countries and a generic any fallback. If a country has complex delivery-point rules, this tool checks the printed format only; it does not verify that a code is currently assigned or deliverable.

Why are credit-card numbers masked?

Masking is on by default so reports, screenshots, and logs do not expose full card numbers. The tool still uses the full input for brand and Luhn checks, then displays only the final four digits. Turn off mask_sensitive only when you explicitly need to inspect the exact normalized digits.

Developer & Automation Access

Run it from the terminal

Same engine as this page, headless — via the gizza CLI:

gizza tool form-field-validator "email: [email protected]
phone: (415) 555-2671
zip: 90210
website: https://example.com
card: 4111 1111 1111 1111"

New to the CLI? Get gizza →

Open it by URL

Pre-fill and auto-run this tool with query parameters — the names match the API/CLI:

https://gizza.ai/tools/form-field-validator/?fields=email%3A%20john%40example.com%0Aphone%3A%20%28415%29%20555-2671%0Azip%3A%2090210%0Awebsite%3A%20https%3A%2F%2Fexample.com%0Acard%3A%204111%201111%201111%201111&country=any&required=email%2C%20phone%2C%20zip&rules=zip%3A%20postal-code%0Acard%3A%20credit-card&normalize=true&mask_sensitive=true&output=text

Machine-readable descriptor: tool.json — title + parameters JSON Schema for agents.