Browser Automation Tool: Fill Web Forms Automatically
Choose a browser automation tool to fill web forms automatically. Follow a Playwright example, handle validation, and reuse a cloud browser for recurring work.
Choose a browser automation tool for your form
To fill web forms automatically, choose a browser automation tool that matches the work: browser autofill for saved personal details, a form-filling extension for repeated manual entries, or a script or AI agent for workflows that span pages and accounts. A cloud browser supplies the remote Chrome environment when those workflows need to run independently of your laptop.
The important question is what happens around the fields. Does the task need to sign in, read a spreadsheet, reveal conditional questions, upload a document, or check that a record was saved? A tool that inserts text into a single page may not handle that entire sequence.
| Approach | Useful when | What you still need |
|---|---|---|
| Built-in browser autofill | You repeatedly enter saved names, addresses, or contact details. | Review and navigation; browser autofill is not a complete workflow runner. |
| Form-filling extension | A person works in the same browser and wants to reuse entries. | Check field matching, data storage, permissions, and support for your target form. |
| Playwright or another script | You know the fields and want explicit, repeatable steps. | Maintain locators, handle validation, and verify the saved record. |
| AI browser agent | The page varies and the workflow needs interpretation. | A suitable model and tools, clear source data, review rules, and result checks. |
| Cloud browser infrastructure | A script or agent needs remote Chrome, a reusable profile, or separate browsers for concurrent tasks. | The automation logic. Cloudbrowser does not infer fields or run a form-filling agent by itself. |
For one occasional form, start with the simplest option. For recurring work behind a login, read about persistent browsers and saved login state. For independent workers, understand parallel browsers and fork isolation before increasing concurrency.
Map the data, fields, and completion signal
Define one input record before building a batch: for example, a name, work email, and team size from a CSV row. Identify each visible label, expected data type, required field, and conditional step. Keep a source record ID outside the browser so a failed run can be reconciled later.
- Read: load one authorized source record and confirm which account should receive it.
- Fill: map values to labels, select options, and checkboxes. Wait for conditional fields to appear.
- Review: inspect the completed values and resolve validation messages.
- Submit: perform the action only when the workflow permits it.
- Verify: check the website’s saved record or confirmation ID, then mark the source row complete.
A successful click is not proof of a successful submission. The form may remain on the page with an inline error, or a request may time out after the website has already saved the record. Plan for both outcomes before retrying.
Example: fill and validate a web form with Playwright
This JavaScript example creates a practice form in a new page, fills text inputs, selects an option, checks a checkbox, and verifies a confirmation message. The practice form stays inside the page. Use it to learn the mechanics before adapting the workflow to a form you control.
In a new local project, install Playwright and its Chromium browser, save the next example as fill-form.mjs, and run it with Node.js:
npm init -y
npm install playwright
npx playwright install chromium
node fill-form.mjsimport { chromium } from 'playwright';
// Without CDP_URL this runs locally. With CDP_URL it uses remote Chrome.
const remote = Boolean(process.env.CDP_URL);
const browser = remote
? await chromium.connectOverCDP(process.env.CDP_URL)
: await chromium.launch({ headless: true });
const context = remote ? browser.contexts()[0] : await browser.newContext();
if (!context) throw new Error('No browser context available');
const page = await context.newPage();
try {
// A self-contained practice form. No customer data or external submission.
await page.setContent(`
<form>
<label>Full name <input name="name" required></label>
<label>Work email <input name="email" type="email" required></label>
<label for="team-size">Team size</label>
<select id="team-size" name="size" required>
<option value="">Choose one</option>
<option value="small">1–10 people</option>
</select>
<label><input name="reviewed" type="checkbox" required> I reviewed this record</label>
<button type="submit">Save practice record</button>
</form>
<p role="status"></p>
<script>
document.querySelector('form').addEventListener('submit', (event) => {
event.preventDefault();
document.querySelector('[role="status"]').textContent = 'Practice record saved';
});
</script>
`);
await page.getByLabel('Full name', { exact: true }).fill('Alex Example');
await page.getByLabel('Work email', { exact: true }).fill('alex' + '@' + 'example.com');
await page.getByLabel('Team size', { exact: true }).selectOption('small');
await page.getByLabel('I reviewed this record', { exact: true }).check();
const valid = await page.locator('form').evaluate(form => form.checkValidity());
if (!valid) throw new Error('Form validation failed');
await page.getByRole('button', { name: 'Save practice record', exact: true }).click();
await page.getByRole('status').filter({ hasText: 'Practice record saved' }).waitFor();
console.log('Practice record saved');
} finally {
await page.close();
// For a CDP connection, close() disconnects this client.
// It does not pause the remote Cloudbrowser resource.
await browser.close();
}The example uses Playwright’s documented form actions: fill() for text, selectOption() for a select, and check() for a checkbox. Label-based locators express which field should receive a value; they also fail visibly when labels are missing or ambiguous. For an unlabeled form, inspect its actual DOM and choose a stable locator rather than guessing.
For a real form you control, replace page.setContent(...) with page.goto(yourFormUrl), then adapt the labels, values, submission rule, and confirmation check. Native checkValidity() checks HTML constraints; it does not prove that custom application validation or a server-side save succeeded. For a review-only workflow, stop before the submit click and leave the page open for a person to inspect.
Run recurring form workflows in a cloud browser
A cloud browser for AI agents is useful when the form workflow needs a browser that can be managed separately from your computer. Cloudbrowser provides Chrome, a saved browser profile, CDP access for automation, and a Live View so an authorized person can observe or interact with the same desktop.
- Create a browser. Use the Console or follow the quickstart. If the form requires a login, sign in through the browser’s desktop.
- Create a CDP link. Open the browser’s Settings and create a CDP link. Treat its URL as a credential with control over that browser.
- Attach your tool. Supply the URL through a
CDP_URLenvironment variable. The practice example useschromium.connectOverCDP()and the existing browser context instead of starting a separate local Chrome. See connection documentation for the connection model. - Check one record first. Observe the run in the Console, confirm that the right account is signed in, and inspect the website’s confirmation.
- Pause after the task. Save the result outside the page, disconnect the automation client, and explicitly pause the browser when finished.
Playwright documents CDP attachment for Chromium and notes that it has lower fidelity than Playwright’s own protocol. Verify the features your workflow needs before moving a local script to remote Chrome.
Cloudbrowser keeps saved profile files across pause and resume, but websites can expire their own sessions. Resume restarts Chrome; unfinished form values and page JavaScript are not guaranteed to survive. Existing, unrevoked CDP links can reconnect after you explicitly resume the browser. Read what state survives pause and resume before using pause as a workflow checkpoint.
Auto-pause is on by default after five minutes without an actual CDP or desktop connection. A connected client or visible Console preview keeps the browser active even without input. Closing your script alone does not guarantee that compute has stopped. See automatic pause behavior and browser-hour billing.
Handle dynamic forms and batches without duplicate submissions
Conditional fields and multi-step pages
Fill prerequisite fields first, wait for the next visible control, and inspect validation before advancing. Use the site’s actual option values for selects. Date pickers, rich-text editors, iframes, and file uploads need their own handling; a text fill command is not a universal substitute.
Retries and partial completion
Keep a small result ledger with the source record ID, state, and destination confirmation ID. Before retrying after a timeout, check whether the destination already contains the record. If the destination has an idempotency key or a unique external reference, use it. Browser automation cannot make a website’s submission endpoint idempotent on its own.
Concurrent workers
Give each worker an independent browser and assign non-overlapping source rows. Multiple CDP connections to one browser still share its tabs and profile. In Cloudbrowser, fork a paused baseline browser when workers should inherit saved profile state; forks receive separate subsequent filesystem writes and do not inherit connection links.
A fork with the same website login can still change the same remote account. Profile isolation does not prevent two workers from creating duplicate records or editing the same destination. Coordinate writes and follow the website’s permitted usage and rate limits.
Keep form data and browser access private
Use only the fields required for the task. Keep credentials out of scripts, screenshots, source control, and public logs. Supply CDP URLs through a secret store or process environment, and avoid printing them on failures. If you use an AI agent, understand which source data and page content its model provider receives.
For Cloudbrowser, CDP grants browser control. Live View uses a separate grant and shared viewing requires account authorization; a view-only link is suitable for an observer, not for someone who must type. Use the access and security documentation to choose permissions and revoke links when no longer needed.
If a website requires fresh authentication or presents a CAPTCHA, handle the challenge through an allowed workflow or ask a person to continue. Cloudbrowser does not promise universal CAPTCHA solving, access to every website, or permanent login validity.
Common questions about automatically filling web forms
Can I automate a web form without coding?
Yes, a form-filling extension or a no-code browser workflow tool may fit. Check whether it can navigate the required steps and verify the result, rather than only insert saved values. Cloudbrowser supplies a browser environment; you still need a tool or agent to perform the workflow.
Do I need AI for form filling?
Not for a known, stable form with explicit field mappings. A deterministic script can be easier to inspect. An AI agent can help interpret varying pages, but its output still needs validation and a completion check.
Can a cloud browser reuse a login?
Saved cookies and local storage can support login reuse. The website controls whether that session remains valid. See the persistent browser guide for the boundary between saved profile data and a live login.
Can I resume an unfinished form after pausing?
Do not depend on it. Save input and progress outside the page. Pausing preserves saved profile data, while resuming restarts Chrome; an unsent form can be lost.
References and next steps
The example follows Playwright’s public APIs. Cloudbrowser behavior is described in the linked product documentation; adapt and validate the workflow against your own form before running a batch.