Help peopleget it right.

Include the script once, add data-parse to the inputs you want to enhance, and supply a public ParseAPI key for your website. Your existing form, field names and submit handler stay in place.

The installation starter prepares the code for your site. Complete Newsletter, Contact and Checkout examples include the extra fields that receive returned data.

Form works with ordinary HTML inputs. You need a way to include JavaScript on the page and add attributes to the actual form controls. A builder that lets you edit both can use the same integration.

Check your builder's restrictions on scripts, custom attributes and embedded forms. Form does not automatically connect to every builder or reach inputs inside another site's iframe. Test the completed form at your submission destination.

Yes. Keep your form state, schema and business rules. Form adds field assistance and ParseAPI results; your library can decide how to display and accept them.

For dynamically mounted inputs, call parseform.scan() after mounting. Controlled inputs must keep framework state in sync with input and change events, or consume Form's parse event in your own components. See framework integration and custom validation.

You choose the fields and their names. Bind returned values to visible or hidden inputs, and they travel with the rest of your form through its normal submission. For example, one full-name input can fill separate first-name and last-name fields.

Form does not create a new submission destination. Missing answers leave generated outputs empty. The field bindings show how to use the names your backend already expects.

Yes. The same script supports fields such as postal codes, countries, cities, measurements, NPI, VIN and IBAN. Supported custom API paths can fill additional details into fields you define.

Choose the field for the job: a format or checksum result, a matching record and a selected suggestion have different meanings. Try the live field examples and browse the complete lookup catalog.

Form gives local guidance for incomplete input, then asks the Email API about email format, the domain's mail routing and disposable status. It can offer a typo correction for the visitor to select. Returned domain details can also fill your own fields.

A passing result does not prove that the mailbox exists, that a message will arrive or that the visitor owns it. Run any mailbox verification you need on your backend after submission; Form does not run that metered check while someone types.

Numbers beginning with + carry their own country calling code. To accept national numbers, supply explicit country context, such as data-parse-country="US". Form never guesses a phone number's country from the visitor's IP address.

The Phone API parses, checks numbering-plan validity and returns standardized formats. That does not establish whether a number is active, can receive a message or belongs to the person entering it. See the Phone reference.

Name parsing supports Unicode letters and single-word names. A single name can produce a first-name value with no last name; keep that possibility in your form and backend instead of requiring a surname from the parser.

Parsing uses first-name-first order unless a comma explicitly marks the surname. It cannot reliably infer every naming convention or establish someone's identity. Keep names editable and use your own acceptance policy where needed. Name reference

Address autocomplete offers US address suggestions. Enter enough of the street and location, then select a suggestion to fill the connected street, city, state and ZIP fields. People can still enter an address manually and add an apartment or suite.

A selected match helps complete the form; it does not confirm deliverability or verify an apartment. Postal-code and city lookups have their own coverage. See the Address and Postal references.

Built-in messages support English, Spanish, French, German, Brazilian Portuguese and Japanese. Form can follow your page or field language, with an explicit override when needed. Your labels, buttons and custom messages remain yours to translate.

The language of returned display labels is a separate setting, as are name-formatting rules. Changing feedback language does not change the submitted values. Try the language examples.

Local email and phone hints need no request. They appear after the visitor leaves a field and update during correction. API checks start when input is ready, after a short pause in typing, and results arrive as requests complete.

You can measure this browser's connection below. This tests the IP endpoint, not a complete field check; typing pauses and other lookups add time. Worldwide speed and status

Once the script has loaded, its local email and phone readiness hints can run without a network request or API key. They explain incomplete input or missing phone-country context; they are not a verified result.

API checks, formatting and returned data still need a connection to ParseAPI. Form is not a complete offline validation engine, and loading the hosted script also needs a connection unless your site has already made it available. An unavailable lookup adds no submission block.

By default, an API result marked invalid or disposable adds a native browser validation error. Required fields, input types and your existing validation continue to apply. Local readiness hints leave the field unchecked and add no new block.

A failed request, missing key, malformed response or timeout adds no block. Form never waits for a pending lookup before submission. The same applies if the script fails to load: your form's own submission and validation remain in charge.

Yes. Manual validation lets your application decide which results to accept, including disposable email. It leaves your native HTML rules and existing validators in place.

You can style Form's built-in helpers or turn them off and build your own interface from its events. Set these options before the fields attach. The UI and validation controls show how; custom interfaces also own their keyboard and accessibility behavior.

Email typo corrections and address suggestions are applied when the visitor selects them. Returned details fill the fields you have explicitly connected. Those fields remain editable.

Form ignores stale results after the source changes and protects edits made while a request is pending. Changing a source clears its previous generated answers so details from an old value do not remain attached to a new one.

Yes. Local email and phone readiness hints work without a key. API checks and returned core data use your public key and the pooled request allowance of your existing ParseAPI plan, including Free. There is no separate Form subscription.

Paid plans add included deep details where supported. Compare the current allowances and plans before choosing the fields and enrichment your form needs.

Usage comes from API requests, not completed form submissions. A form with several marked fields can make several requests, and editing a value can trigger another check. The script waits for ready input and a typing pause; local hints do not use API requests.

Form supports included lookups and eligible deep enrichment. Metered mailbox, carrier and similar checks belong on your backend after submission; the script does not run them while a visitor types.

Yes: use a public key, restricted to your website's allowed domains. Public keys are designed for browser use and are visible in the page. Form refuses secret keys.

The setup flow prepares a public key for your site and its subdomains. Use a localhost allowance for local testing, and manage allowed domains or revoke keys in API keys. Keep your secret server key on your server.

Configured field values and their lookup context are sent to ParseAPI for the requested checks. For example, a phone lookup can include its configured country. Your complete form submission goes through your existing backend or form destination.

IP and browser enrichment is a separate opt-in. When enabled for a form, those lookups run after its first non-empty edit, rather than on page load or focus. See optional visit details, the Privacy Policy and Security.

All browser values remain editable by the client, including hidden inputs and Form's status attributes. Use them to assist the visitor and carry useful details; validate the data your backend relies on before making an acceptance or security decision.

When a server decision needs fresh API evidence, request it on the server with your secret key. For visitor context, use the incoming request and trusted proxy configuration; a submitted IP field is not proof of the connection. The server example shows that boundary.