Most people who ask me about browser automation tools want the same thing: a website holds data they need, or a repetitive task lives inside it, and doing it by hand is eating their week. The list below is the one I actually work from. It runs from a browser extension you can set up in an afternoon to a Python script that runs unattended on a schedule. The right choice depends less on your skill level than on how often the job runs and how much breakage you can live with.
What these tools actually do
A browser automation tool drives a real web browser the way a person would: open a page, wait for it to load, click a button, type into a field, read text off the screen, move on. That is different from calling an API, where you ask a server for data directly and get back structured JSON. Automation is the fallback for when there is no API, or when the API costs more than the problem is worth.
Two terms worth defining now, because they turn up in every single job:
Selector — the address of an element on a page, usually a CSS selector like .product-price or an XPath. If the site's developers rename that class, your bot stops finding the price. This is the most common reason a working scraper suddenly stops working.
Headless — running the browser with no visible window. Faster and cheaper on a server, but some sites behave differently when they can tell no screen is attached.
No-code browser automation for one-off jobs
If a task runs once a month and takes twenty minutes by hand, you do not need a Python project. You need a macro.
UI.Vision RPA
UI.Vision is a browser extension that records what you click and replays it. RPA stands for robotic process automation, which is a heavy name for a simple idea: the software does the clicking. You can save a recording, edit the individual steps, and run it against a list of URLs from a CSV file.
It suits form filling, bulk downloads, and moving data between two internal systems that will never speak to each other directly.
Automa
Automa is the other extension I reach for. Instead of a linear recording, you build a flow out of blocks — go to page, wait, click, extract text, loop, export. Being able to see the flow as a diagram makes it much easier for a client to understand what their own automation is doing, and to change it later without calling me.
Automa also handles conditional logic reasonably well, so "if this element exists, click it, otherwise skip" is a two-block change rather than a rewrite.
Where no-code runs out
Both tools live inside your browser, which means your computer has to be on and awake for anything to happen. Neither handles thousands of pages gracefully. Neither gives you a clean error log when something fails at 3am. When a client asks for a schedule, a retry policy, or a real database at the end of it, I move the job to code.
When the job needs code: Playwright and its alternatives
Playwright is a Python and JavaScript library that controls Chromium, Firefox, and WebKit. It is my default for anything scheduled, anything large, or anything that has to survive a site redesign without a person watching. The official Playwright documentation for Python is the reference I keep open while building.
Building a Playwright web scraper buys you things the extensions cannot offer: automatic waiting for elements instead of guessing with fixed delays, running many pages in parallel, and running on a server so the job continues when your laptop is shut. Errors come back as real messages — TimeoutError: Timeout 30000ms exceeded tells you exactly which step hung, and which selector to fix.
Selenium and Puppeteer solve the same problem. Selenium is older, has the widest language support, and turns up in a lot of existing corporate test suites. Puppeteer is Chrome-focused and lighter. If you already have a working Selenium setup, I will extend it rather than insist on a rewrite. For a new build with no history behind it, Playwright takes less code to do the same work.
Small fixes with Tampermonkey and Chrome extensions
Not every problem needs a bot that runs on its own. Sometimes the fix is changing how a page behaves while you are looking at it.
Tampermonkey runs custom userscripts — small pieces of JavaScript that alter a page after it loads. It can add a download button that a site never gave you, strip a layout that fights you, expose a hidden field, or copy a table to the clipboard in one click. A private Chrome extension does the same job with more structure when the tool needs to be shared across a team.
These are the cheapest wins available. The work is measured in hours rather than days, and the result is something the client's staff use directly instead of a file that lands in their inbox.
Where the data goes after the bot runs
A scraper that produces nothing usable is half a job. Extraction is the visible part; the storage decision is the part that determines whether anyone actually uses the output.
For a one-time pull, CSV is fine. For anything recurring, I usually write to SQLite, which is a single database file with no server to run, or to PostgreSQL when several people need to query it at once. When the client's team lives in a spreadsheet, Google Sheets or Airtable is the right destination, because a pipeline nobody opens has no value.
Cleaning happens before storage: consistent date formats, deduplicated rows, prices as numbers rather than text with currency symbols attached.
API automation workflow tools: Zapier, n8n, MAKE.com
Once data is moving, you often want something to happen next. Zapier, n8n, and MAKE.com connect services to each other without custom code — new row in a sheet triggers an email, a webhook fires when a record changes, a REST or GraphQL endpoint gets called on a schedule.
n8n is the one I suggest most often, because it can be self-hosted, which keeps client data on infrastructure the client controls and avoids per-task pricing on high-volume runs. Zapier is the fastest to set up if volume is low and the connectors you need already exist.
Server automation with Ansible
Ansible sits one layer below all of this. It is a configuration management tool — it defines what should be installed and configured on a machine, then makes the machine match that definition. It is the standard choice for this job in Linux environments, and the Ansible getting-started guide covers the basics well.
For automation work specifically, it matters when a scraper graduates from your laptop to a server and you need Python, browser dependencies, and a scheduler installed the same way every time.
Trading automation is a separate track
VectorBT and backtesting.py are the tools for automated trading strategy work. I include them because people ask, but they solve a different problem — testing a strategy against historical price data rather than getting data out of a website. They are not part of the stack described above, and I do not take trading bot work.
Terms of service and robots.txt
I will describe what is technically possible on any site you bring me. Whether you should automate against it is your call, not mine. Check the site's terms of service and its robots.txt file before commissioning a build. Google's introduction to robots.txt explains how that file works if it is new to you.
Picking the right one for your job
Runs occasionally, small volume, you are at the keyboard anyway — UI.Vision or Automa. Runs on a schedule, large volume, needs to survive without supervision — Playwright. Fixing how one page behaves for your own team — Tampermonkey or a Chrome extension. Connecting tools that already hold your data — n8n or Zapier.
If you would rather skip the tool selection entirely, the overview of the automation services I offer covers the six areas I build in, and you can start a custom scraper or automation build with me directly. More write-ups on scraping and automation are collected in the DatafetchPro article archive, and there is background on how I work on the page about me and my process.