Browser Automation Tools That Fill Web Forms Automatically: 5 Options Compared
Somewhere in your company, someone copies a row from a spreadsheet, pastes it into a web portal, clicks Submit, and does it again. Sometimes it happens 40 times a day. Sometimes 4,000. The portal could be a carrier site, a state filing system, a supplier dashboard or an old internal tool. None of them offers an API you can use, so the form is the only way in.
There are plenty of tools that promise to fill web forms for you. They don’t all solve the same problem, though. A Chrome extension that fills in your shipping address is a very different thing from a system that submits 2,000 claims a week through a portal protected by MFA.
This guide covers the five main types of browser automation tools for filling web forms, what each one does well, where each one breaks, and how to choose one for your use case.
The Short Answer
A browser automation tool fills web forms automatically by opening a web page, finding each field, entering data from a source such as a spreadsheet, database or API call, and submitting the form the way a person would. Your options fall into five groups:
| Approach | Best for | Breaks down when |
|---|---|---|
| Autofill and form-filler extensions | One person filling the same personal or profile details again and again | You need volume, other people’s data, or anything running unattended |
| No-code browser bots | Ops teams moving spreadsheet rows into one or two sites | Forms change, logins expire, or volume grows past a few hundred runs |
| Scripts (Playwright, Selenium, Puppeteer) | Engineers automating a small number of stable sites | You have many sites, frequent UI changes, or MFA on every login |
| AI browser agents | Forms that vary, or tasks that need reading and judgment on the page | You need repeatable results, audit trails, and predictable cost at scale |
| Managed portal infrastructure (e.g., Deck) | Production form submissions on login-protected portals with no API, at volume | You only need to fill one form, once |
The rest of this article goes through each option and then covers the part most guides leave out: what happens when the form sits behind a login.
What “Filling Web Forms Automatically” Actually Involves
Typing values into boxes is the easy part. A complete form-filling automation has to:
- Get the data from a spreadsheet, CRM, database, webhook or API request.
- Get to the form, which usually means logging in, getting past MFA, and navigating to the right page.
- Map each value to the right field, including dropdowns, date pickers, radio buttons, file uploads and fields that only appear after an earlier answer.
- Handle multi-step forms that span several pages and can time out between steps.
- Submit and confirm by capturing the confirmation number, the success message or the error.
- Return the result to the system that asked for it.
- Do it all again, reliably, after the site changes its layout.
Most tools handle step 3 well. They differ on steps 2, 5, 6 and 7, and those are the steps that decide whether an automation survives production.
1. Autofill and Form-Filler Extensions
Examples: your browser’s built-in autofill, Chrome Web Store form fillers, AI auto-fill extensions
Browser autofill remembers your name, address and card details. Form-filler extensions go further: they save profiles, fill fields based on rules, and in newer AI versions they read a page and guess which saved value belongs in which field.
Good for
- Filling your own details into sign-up, checkout and job application forms
- QA testers who need test data in a form quickly
- Saving a few minutes a day for one person
Limits
- A person still has to open each page and click Submit, so this saves typing, not work.
- It doesn’t run on a schedule, from a trigger, or without someone at the keyboard.
- Profiles are built for one person’s data, not thousands of customer records.
Verdict: These are useful personal tools. They aren’t really automation.
2. No-Code Browser Bots
Examples: Axiom.ai, browser-based RPA recorders, Zapier-style tools paired with a browser step
No-code bots run inside a Chrome extension or a cloud browser. You point at each field, link it to a column in Google Sheets or Excel, and the bot loops through the rows. Most support waits, clicks, key presses and basic conditions.
Good for
- Ops and admin teams moving spreadsheet data into one or two web apps
- Runs in the tens or low hundreds that someone can watch
- Teams without engineering time
Limits
- Logins are fragile. The usual advice is to save cookies so the bot stays signed in. When the session expires or an MFA prompt shows up, the run stops.
- Long forms need workarounds. Multi-page forms often have to be split into several bots chained together.
- Selectors break. When the site moves a field or renames a button, someone has to re-record the step.
- Visibility is limited. It’s hard to tell which rows went through, which failed, and why.
Verdict: A good fit for one team, one site and moderate volume. It becomes a maintenance job once any of those grows.
3. Scripts: Playwright, Selenium and Puppeteer
Examples: Playwright, Selenium WebDriver, Puppeteer, open-source auto-fill repos on GitHub
An engineer writes code that opens a browser, finds each field with a CSS or XPath selector, fills it and submits. This is the most flexible option and the most common one in developer tutorials.
Good for
- Engineering teams automating a few stable sites
- Full control over logic, retries and data handling
- Testing your own application, which is what these frameworks were built for
Limits
- Every site is its own project. Ten portals mean ten scripts, ten login flows and ten sets of selectors to keep working.
- Authentication is on you. Storing credentials safely, handling TOTP and SMS codes, refreshing sessions and dealing with antibot checks is a large engineering project that sits outside the form itself.
- Maintenance never ends. Portals change without notice, and someone has to notice the break and fix it.
- Infrastructure is on you. Headless browsers, proxies, concurrency, queues and logging all need building.
Verdict: The right tool for a few sites you control or know well. For a long tail of third-party portals, the total cost grows quickly. (We compare the two approaches in Deck vs Playwright.)
4. AI Browser Agents
Examples: Skyvern, Claude in Chrome, Gemini in Chrome, agent modes in AI assistants, open-source agents such as Browser Use
AI browser agents swap hard-coded selectors for a model that looks at the page through screenshots, the DOM or both, and decides what to do. You give it a goal and the data (“submit this address change using these details”) and it finds the fields itself.
Good for
- Forms that differ from site to site, or change often
- One-off or low-volume tasks where writing a script isn’t worth it
- Tasks that involve reading the page as well as typing into it
Limits
- Results vary between runs. The same prompt can take different paths on different runs. That’s acceptable for a personal errand, but risky when a wrong field means a rejected filing.
- Logins are still the hard part. Many agents can use a stored password. Rotating 2FA codes, step-up authentication, SSO redirects and antibot checks on enterprise portals are a harder problem, and few vendors publish production results for it.
- Cost and speed. Every step calls a model. At thousands of submissions, that adds up in money and in time.
- Proof. Regulated workflows need to show what was submitted, when, and on whose authority. A chat transcript doesn’t meet that bar.
Verdict: AI agents make it possible to automate forms that scripts couldn’t handle. On their own, they don’t make that automation reliable enough for production.
For a wider view, see our guide to computer use agents and our comparison of computer use agent platforms.
5. Managed Portal Infrastructure
Example: Deck
The fifth option treats form filling as an infrastructure problem instead of a scripting one. You don’t build and maintain a bot for each site. You call one API with the data and the target portal, and the platform handles everything between your request and the confirmation number: login, MFA, navigation, filling, submission and returning structured results.
This is how Deck works. Deck connects to web portals whether or not they have an API. Your application calls Deck’s API, Deck’s agents log in to the target site with the user’s authorization, complete the task, and return clean JSON to your system.
Good for
- Platforms and enterprises submitting forms on many third-party portals
- Login-protected portals with MFA, where cookie-based bots keep failing
- Regulated data such as financial, insurance, healthcare or payment information
- Teams that want the form-filling step to behave like an API call in their existing workflow
What’s different
- Authentication comes built in. Encrypted credential storage, live MFA handling and session management are part of the platform. You don’t rebuild them for each site.
- Pre-built connections. Deck already connects to more than 100,000 login-protected portals, so many of the sites you need are working on day one.
- Maintenance belongs to the vendor. When a portal changes, keeping the connection working is Deck’s job.
- Compliance. Consent and audit logging come standard, backed by SOC 2 Type II and PCI DSS Level 1 certification.
- Structured output. Confirmation IDs, statuses and errors come back as data your systems can act on, not as screenshots.
Limits
- More than you need if you’re filling one form for yourself.
- It’s a developer platform. Someone on your team integrates with Deck’s API to trigger tasks and receive results.
Verdict: Built for the case where form submission is part of your product or operations and has to work every time, on sites you don’t control.
Where Most Form Automation Fails: The Login
Ask any team that has automated form filling in production and they’ll tell you the form was rarely the problem. The login was.
Before any field gets filled, the automation has to:
- Store credentials safely for every user and every portal. A spreadsheet of passwords doesn’t count.
- Handle MFA with codes by SMS, email or authenticator app, sometimes on every login and sometimes only when something looks unusual.
- Keep sessions alive, or notice when they’ve expired and sign in again without submitting the same form twice.
- Get past antibot checks without breaking the portal’s terms or locking the account.
- Respect consent. When you act on a user’s behalf, you need a record that they authorized it.
Extensions and no-code bots mostly avoid this by assuming someone is already logged in. Scripts and AI agents can handle it, but you build and maintain that layer yourself, for every portal. That’s the main reason form-filling projects that work in a demo stall in production.
For more detail, see what an authentication agent is and our computer use agent security guide.
A Production Checklist for Automated Form Filling
Whatever tool you pick, check it against this list before you rely on it.
- Data validation before submit. Does it check required fields, formats and allowed values before it touches the form?
- No duplicate submissions. If a run fails halfway and retries, could it submit the same claim, order or filing twice?
- Confirmation capture. Does it record the confirmation number or the portal’s response, or just assume success?
- Error handling. Does it tell “the portal rejected this value” apart from “the page didn’t load,” and retry only the second?
- Change detection. When the portal changes its layout, do you find out from an alert or from an angry customer?
- Credential security. Where are passwords and MFA secrets stored, who can access them, and are they encrypted?
- Audit trail. Can you show what was submitted, when, and under whose authorization?
- Sensitive data handling. Are personal or payment details kept out of logs and screenshots?
- Concurrency. Can it run hundreds of submissions in parallel without tripping rate limits or account locks?
If a tool fails three or more of these, it’s fine for convenience but not for production.
How to Choose: Three Questions
1. Is anyone watching each submission?
If a person reviews every form before it’s submitted, an extension or no-code bot is enough. If submissions run unattended from a trigger or schedule, you need something with real error handling and confirmation capture.
2. How many different sites?
For one or two stable sites, a script or no-code bot is reasonable. For dozens or hundreds of third-party portals, each with its own login flow, building per-site automation becomes a permanent engineering cost. That’s where pre-built connections pay off.
3. Is there a login, and whose account is it?
For a public form with no login, almost any tool works. If it’s your company’s account on one portal, scripts with careful secrets management can work. If you’re submitting on behalf of many users, each with their own credentials and MFA, you need authentication infrastructure. Don’t hand-roll it.
Example: Form Filling as One Step in Your Workflow
Here’s a pattern we see often. An insurance platform needs to submit claims to dozens of carrier portals. Most carriers have no API.
The platform’s own system already does the important work. It takes the claim, validates it, and decides which carrier gets it. The one step it can’t do is the submission itself, because that means logging in to a carrier portal and filling out a form.
That’s the step Deck handles:
- The platform’s workflow calls Deck’s API with the claim data and the target carrier.
- Deck logs in to the carrier portal, handles MFA, fills the claim form, attaches documents and submits.
- Deck returns the confirmation number and status as structured JSON.
- The platform’s workflow takes over again: it updates the claim record, notifies the customer, and decides what happens next.
The business logic stays where it was. Deck runs the one task that needed a browser, and the form-filling step becomes as dependable as any other API call in the pipeline.
The same pattern applies to vendor onboarding forms, benefits enrollment, government and tax filings, supplier order entry, and accounts payable portals.
FAQ
What is the best browser automation tool to fill web forms automatically?
It depends on scale and logins. For personal use, a form-filler extension is enough. For moving spreadsheet rows into one site, a no-code bot like Axiom.ai works well. Engineers automating a few stable sites usually pick Playwright. For production submissions across many login-protected portals with no API, managed infrastructure such as Deck saves you from building authentication and maintenance yourself.
Can I automatically fill web forms from a spreadsheet?
Yes. No-code bots and scripts can both read rows from Google Sheets, Excel or a CSV and submit one form per row. For high volume or login-protected sites, send the rows through an API-based platform so every submission returns a confirmation and failures can be retried safely.
Can AI fill out web forms automatically?
Yes. AI browser agents read a page and work out which value goes in which field, even on forms they haven’t seen before. They handle variety well. For high-volume or regulated submissions, pair them with authentication, validation and audit logging so results stay consistent and traceable.
How do you automate a form that’s behind a login with 2FA?
The automation needs secure credential storage, a way to receive or generate the 2FA code (TOTP secret, SMS or email relay), and session handling that signs in again without resubmitting the form. You can build this yourself for each portal, or use a platform like Deck where authentication and MFA handling are built in.
Is automated form filling legal?
Automating forms you’re authorized to submit, such as your own accounts or your users’ accounts with their consent, is standard practice. Read each portal’s terms, get explicit user authorization when acting on someone’s behalf, and never use automation for spam, fraud, vote manipulation or getting around access controls.
What’s the difference between RPA and AI browser agents for form filling?
RPA follows recorded steps and fixed selectors, so it’s predictable but breaks when the page changes. AI browser agents decide each step from what’s on screen, so they adapt better but are less consistent between runs. More on this in computer use agents vs RPA.
Submit Forms on Any Portal, Even Ones With No API
If your team is maintaining a stack of form-filling scripts, re-recording bots after every portal update, or still paying people to copy and paste into websites, the problem isn’t your tool’s form-filling. It’s everything around it: logins, MFA, maintenance and proof.
Deck handles that layer. You call one API and Deck submits the form on the portal, whether or not that site has an API.
Ready to get started?
See how Deck can connect your product to any system — no APIs needed.
Build my Agent →
