Selenium IDE: Browser Automation Without Writing Code

Selenium IDE lets you record browser actions and replay them as a test without hand-writing Selenium commands. Install the IDE, create a project with your application’s base URL, record a representative flow, review it, save the project as a .side file, and play the test back. The Selenium project lists Chrome, Firefox, and Edge for the IDE. Recording can get a first test started quickly; cross-browser and Selenium Grid execution use the command-line runner and require additional setup.

What Selenium IDE does—and what “without code” means

The Selenium project describes Selenium IDE as “a browser extension that records and plays back a user’s actions.” It translates interactions such as clicking, typing, and navigation into Selenium commands that can be replayed. See the official Selenium IDE overview.

For a beginner, the no-code path is authoring a basic recorded test in the IDE and replaying it there. You still need to choose a useful flow, inspect the generated steps, and update the test when the application changes. Running tests across browsers or on Grid is a separate workflow using selenium-side-runner, browser drivers, and potentially Node/npm configuration.

Install Selenium IDE

Open the official Selenium downloads page.
Choose the Selenium IDE download or browser-store link for the browser you intend to use.
Install it and launch the IDE. Store availability and compatibility can change, so use the current official download page rather than an old third-party installation guide.

Selenium’s project materials span different versions and architectures. Older help pages describe the extension workflow, while v4 project notes discuss moving away from a webextension. Treat old filesystem instructions and old Node version requirements as historical; check the current download, release, and runner documentation for your installation. The v4 project notes explain the historical architecture decision.

Record and replay your first browser test

Create a project. Start a new project, enter a project name, and set its base URL to the application under test. The base URL is shared by tests in the project and can be changed later.
Record a representative flow. Start recording, interact with the site as a user would, and complete one focused task. For example, open a page, fill in a search field, submit the search, and open a result. Use a test account and non-destructive actions.
Stop and review. Inspect the recorded commands. Confirm that the test is exercising the intended elements and that the sequence does not depend on incidental page state.
Save the project. Save it as a .side file. The getting-started guide describes a project as a single file containing its tests.
Replay the test. Select the test or suite and use the IDE playback control. The guide says playback uses the open recording window when available; otherwise, it opens a new browser window.
Check the result and revise. If the replay fails, inspect the failing command and current page state, adjust the flow or test data, then replay.

Keep each test focused on one user outcome. A long recording is harder to diagnose when a page changes or an early step fails. Re-recording is not a substitute for reviewing the steps: a locator or assumption captured today can become stale after an interface change.

What happens during playback

The IDE replays the saved commands in a browser. Playback is useful for checking a recorded flow in the IDE’s supported environment. It does not itself provide a hosted browser farm or remove the need to configure a command-line runner for broader browser coverage.

Think through state before replay: is the test account still valid, does the test start from a predictable page, and will a previous run have changed server-side data? Prefer repeatable setup and safe test data. If the flow depends on a one-time email, changing inventory, or a third-party service, replay can fail for reasons unrelated to the recorded click sequence.

When to use the command-line runner

Use selenium-side-runner when you need to run a saved .side project outside the IDE, select tests for automated execution, use browser-specific local execution, or connect to Selenium Grid. Selenium’s runner guide documents local browser and driver setup, Grid configuration, test filtering, and parallel workers. Consult the current runner guide for the exact commands and prerequisites; its older Node 8/10 prerequisite text is legacy guidance and should not be copied as current.

Local execution checklist

Install a currently supported Node.js/npm environment as required by the runner version you install.
Install the target browser.
Install and configure the matching driver where required: ChromeDriver for Chrome, EdgeDriver for Edge, or geckodriver for Firefox. Safari has its own driver and platform requirements.
Install the runner using the current official instructions, then pass the saved .side project to it.
Run one browser and one test first; expand to other browsers or workers after local configuration works.

For Grid, configure the runner with the Grid server URL and desired browser capabilities. Grid availability, browser versions, and capacity are properties of your Grid environment. Increase parallel workers only after checking that the host or Grid can support the extra sessions.

Cross-browser and Grid execution

The IDE overview lists Chrome, Firefox, and Edge, but the recording workflow and the runner workflow are distinct. A test that replays in one browser is not proof that it passes in every browser. Browser behavior, drivers, installed versions, and environment-specific settings can differ.

Make the test pass locally in one browser.
Install and configure the additional browser and its matching driver.
Run the same saved project against that browser with the command-line runner.
For a remote Grid, configure its URL and browser capabilities, then confirm sessions can be created before enabling parallel jobs.
Filter or split tests as appropriate; use parallel workers only when the Grid has available capacity.

The runner documentation also names hosted Grid providers such as Sauce Labs as an example of a remote execution path. Verify the current provider setup and terms independently before choosing one.

Keeping recorded tests reliable

Record stable user paths. Avoid unnecessary navigation and actions that change frequently.
Review after recording. Confirm each step represents the intended action and succeeds from a clean starting state.
Use controlled test data. Replays can fail if accounts, records, or third-party state have changed.
Update tests with the application. A changed page structure or workflow can make recorded steps obsolete.
Separate authoring from coverage. A successful IDE replay is one useful check; command-line and Grid runs are needed for their respective environments.

Common problems and fixes

Symptom	Likely cause	What to do
The IDE is unavailable in the browser store or does not match an old guide.	Store listings and product architecture change; older Selenium IDE documentation describes earlier extension behavior.	Start from the official downloads page and check the current IDE release notes. Do not assume an old extension-specific troubleshooting step applies to v4.
A recorded test opens the wrong page.	The project base URL or starting state is not what the test expects.	Check the project base URL and begin playback from a predictable state.
A click or typing step fails during replay.	The page changed, the target is not available yet, or the flow relies on different data/state.	Inspect the failing step and page, confirm the target and test data, then update and replay the test.
In-IDE playback works, but runner execution fails.	The local browser, driver, Node/npm environment, or runner configuration is missing or incompatible.	Follow the current runner prerequisites and verify the browser-driver pairing and runner installation before debugging the test itself.
A Grid run cannot create a session.	The Grid URL or browser capabilities are incorrect, or the Grid lacks a matching available browser.	Check the server URL, requested capabilities, and Grid browser availability. Test a single session before increasing workers.
Parallel runs fail intermittently.	Worker count may exceed available Grid capacity, or tests may share mutable data.	Reduce workers and isolate test data; increase parallelism only when the environment can sustain it.
An old FAQ says the project cannot be saved or discusses extension filesystem limits.	That advice refers to an older browser-extension access model.	Use the current IDE’s save workflow and current documentation rather than applying the historical workaround.

Performance, reliability, and cost

Selenium IDE itself is a way to author and replay tests; execution time and reliability depend on the page, browser, test flow, drivers, and any Grid or CI environment. Long flows, unstable data, and excess parallel sessions make failures harder to isolate. Keep initial tests focused, establish a passing local run, and add browsers or workers in measured steps.

The cited Selenium materials do not establish a universal run-time benchmark or a price for hosted browser execution. The IDE project and browser/driver tooling are software, while Grid hosting may involve infrastructure or a provider’s pricing. Check current provider terms if you choose hosted execution.

Or skip the browser setup

If the job is to capture a page as an image or PDF rather than test a sequence of interactions, ScreenshotNeo is a direct website screenshot API and MCP server. Selenium IDE automates browser actions; ScreenshotNeo captures a page in one request. The API accepts a URL and returns PNG, JPEG, WebP, or PDF. See the ScreenshotNeo API documentation.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', Buffer.from(await res.arrayBuffer())));

Replace YOUR_API_KEY with an API key and change the target URL as needed. The Python example requires the requests package. The Node.js example uses built-in fetch and filesystem APIs in a modern Node runtime.

Cookie and consent banners are accepted like a visitor, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off.
Bot checks/CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed. Response headers report the page verdict and billing status.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
There are 1,000 screenshots per month free with no card; paid plans start at $5 for 3,000. Every feature is on every plan.

Frequently asked questions

Can Selenium IDE automate browser actions without writing code?

Yes. You can record actions and replay the resulting Selenium commands in the IDE. Reviewing and maintaining a useful test still takes judgment.

Can I use Selenium IDE with Chrome, Firefox, and Edge?

The official overview lists all three. Check current download availability, and use the command-line runner for the browser-specific and Grid workflows described in its documentation.

Does a recorded test replace a full test strategy?

No. It provides a practical way to create and replay a browser flow. Teams still need to choose test coverage, maintain test data, and run tests in the environments they support.

Is ScreenshotNeo a replacement for Selenium IDE?

No. Selenium IDE records interactive user flows for testing. ScreenshotNeo captures a requested page as an image or PDF and offers an MCP interface for screenshot tasks.