Practical Example: Testing a Login Form

Consider a login page with email and password fields plus a submit button. Here’s how to record a login test: Start Selenium IDE and enter https://your-app.example.com/login Click the record button Click into the email field and type testuser@example.com Click into the password field an...

Selenium IDE Recorder Chrome Extension (2026)

Last updated: April 17, 2026

The Selenium IDE Chrome extension transforms browser interaction recording into executable test automation. This tool records your actions as you navigate a website, then replays them as automated test scripts, without requiring you to write code from scratch. For teams that need fast test coverage and for developers new to automation, it removes the blank-page problem that stops many automation projects before they start.

What Is Selenium IDE?

Selenium IDE (Integrated Development Environment) is a browser extension available for both Chrome and Firefox. Originally released as a Firefox add-on in 2006, it was sunset by Applitools around 2017 and then rebuilt from scratch by the Selenium project in 2018 to support modern browser extension APIs. The current version is actively maintained and far more stable than its predecessor.

The Chrome extension version offers identical functionality within the Chromium ecosystem. You install it from the Chrome Web Store, and it immediately becomes available as a toolbar icon.

Core capabilities include:

Recording user interactions against any website
Playing back recorded sequences automatically
Exporting tests to multiple programming languages
Supporting control flow logic (loops, conditionals)
Organizing tests into suites
Running tests in parallel via the selenium-side-runner CLI tool
Plugging in custom commands through the user-extensions API

Installing and Setting Up

To install the Selenium IDE Chrome extension:

Open Chrome and navigate to the Chrome Web Store
Search for “Selenium IDE”
Click “Add to Chrome” and confirm the installation
The Selenium IDE icon appears in your toolbar

After installation, clicking the icon opens the Selenium IDE interface in a new tab. You can create new projects, open existing ones, or start recording immediately.

When you create a new project, Selenium IDE saves it as a .side file. a JSON-formatted project file that stores all test suites, individual tests, and project-level settings. Commit this file to version control just like source code. Teams often store .side files alongside the application they test, which makes test updates part of the same pull request as feature changes.

Recording Your First Test

The recording workflow follows three basic phases:

Start Recording

Click the red record button in the Selenium IDE toolbar. Enter a base URL. the starting page for your test. The extension begins capturing every click, type, and navigation action.

Perform Actions

Navigate through your target website as a user would. Click buttons, fill forms, navigate between pages. Selenium IDE records each action with its target element and command. As you interact with the page, the command list in the IDE sidebar updates in real time. you can watch commands appear as you click.

Stop and Save

Click the record button again to stop. Review the command list in the sidebar. Each action appears as a row with command, target, and value fields. Before saving, scan through the recorded steps and delete any accidental clicks or spurious mouseover events that crept in. Clean recordings run faster and are easier to maintain.

Understanding Commands and Locators

Selenium IDE uses a command-based syntax. Each row represents an action or assertion:

command: click
target: id=submit-button
value:
command: type
target: id=email-field
value: [email protected]
command: assertTitle
target: exact:Dashboard
value:

Locators identify web elements. Selenium IDE automatically selects a locator strategy, but you can modify it in the target field. Common locator strategies include:

id: id=login-button
name: name=username
css: css=#nav .menu-item
xpath: xpath=//button[@class='primary']
link text: link=Sign Up

The Chrome extension automatically chooses the most reliable locator, typically preferring id when available, then falling back to CSS or XPath. You can override this by specifying the strategy explicitly, or by clicking the small dropdown arrow next to the target field to see alternative locators Selenium IDE found for that element. This is invaluable when the auto-selected locator is fragile. you can often find a more stable alternative in the same list.

Locator Strategy Comparison

Strategy	Stability	Readability	Performance	When to Use
id	High	High	Fastest	Always when available
data-testid	Very High	High	Fast	When devs add test hooks
name	Medium	High	Fast	Form inputs with name attributes
CSS selector	Medium	Medium	Fast	Class-based or attribute targeting
XPath	Low	Low	Slower	Last resort for complex DOM traversal
Link text	Medium	High	Medium	Navigation links only

The single most impactful thing a development team can do to improve test reliability is to add data-testid attributes to key interactive elements. Ask your developers to add data-testid="login-submit" to important buttons and form fields. this gives your Selenium tests a stable anchor that survives CSS refactors and DOM restructuring.

Consider a login page with email and password fields plus a submit button. Here’s how to record a login test:

Start Selenium IDE and enter https://your-app.example.com/login
Click the record button
Click into the email field and type [email protected]
Click into the password field and type securePassword123
Click the submit button
Wait for the dashboard to load
Stop recording

The recorded sequence produces commands like:

open
/
type
id=email
[email protected]
type
id=password
securePassword123
click
css=button[type=submit]
assertText
css=.welcome-message
Welcome, Test User

After reviewing, you would typically add a waitForElementVisible before the final assertText to handle network latency, and swap the auto-generated css=button[type=submit] for css=[data-testid=login-submit] if your app has that attribute set.

Exporting to Code

Selenium IDE transforms recorded tests into executable code. Click the “Export” button to choose your target language:

Java (JUnit/TestNG)
Python (pytest)
C# (NUnit)
JavaScript (WebDriverIO, Protractor, Jest)
Ruby (RSpec)

The export generates a complete test file with WebDriver initialization, element location, and assertions. For Python pytest, the output resembles:

import pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.chrome.service import Service
def test_login():
 driver = webdriver.Chrome()
 driver.get("https://your-app.example.com/login")
 driver.find_element(By.ID, "email").send_keys("[email protected]")
 driver.find_element(By.ID, "password").send_keys("securePassword123")
 driver.find_element(By.CSS_SELECTOR, "button[type=submit]").click()
 welcome = driver.find_element(By.CSS_SELECTOR, ".welcome-message").text
 assert "Welcome" in welcome
 driver.quit()

This exported code becomes the foundation for a more sophisticated test suite. The generated file is intentionally minimal. it does not include fixtures, teardown hooks, or page object structure. Treat it as a starting draft, not a finished product.

Improving Exported Python Tests

Here is how to harden the exported code with explicit waits and proper teardown:

import pytest
from selenium import webdriver
from selenium.webdriver.common.by import By
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
@pytest.fixture
def driver():
 options = webdriver.ChromeOptions()
 options.add_argument('--headless')
 d = webdriver.Chrome(options=options)
 d.implicitly_wait(0) # disable implicit wait; use explicit waits instead
 yield d
 d.quit()
def test_login_with_valid_credentials(driver):
 wait = WebDriverWait(driver, timeout=10)
 driver.get("https://your-app.example.com/login")
 wait.until(EC.element_to_be_clickable((By.ID, "email"))).send_keys("[email protected]")
 driver.find_element(By.ID, "password").send_keys("securePassword123")
 driver.find_element(By.CSS_SELECTOR, "button[type=submit]").click()
 welcome = wait.until(
 EC.visibility_of_element_located((By.CSS_SELECTOR, ".welcome-message"))
 )
 assert "Welcome" in welcome.text

The WebDriverWait + expected_conditions pattern eliminates the timing guesses that make raw Selenium tests flaky in CI environments where network latency is unpredictable.

Adding Control Flow

Beyond simple recording, Selenium IDE supports logic constructs through its user-extensions API. You can add:

Conditions: Execute commands only when specific elements exist
Loops: Repeat actions across multiple items
Variables: Store and reuse values between steps

Access control flow through the “Add” menu in the toolbar. Select if, while, or times to insert logic blocks into your test.

A practical use of control flow is handling optional UI elements like cookie consent banners or promotional modals that appear intermittently:

if | isElementPresent | css=[data-testid=cookie-banner]
click | css=[data-testid=accept-cookies] |
end

This pattern prevents the test from failing on pages where the banner appears while still running cleanly when it does not. Without this, you would need two separate test paths or a custom executeScript workaround.

Using Variables

Variables let you capture dynamic values from the page and reference them later in the same test:

storeText | css=.order-number | orderNumber
open | /orders/${orderNumber} |
assertText | css=h1 | Order ${orderNumber}

The ${variableName} syntax works in any target or value field. Variables reset between test runs by default, so there is no state leakage between tests.

Running Tests from the Command Line

Selenium IDE tests can run headlessly in CI pipelines using selenium-side-runner:

npm install -g selenium-side-runner
selenium-side-runner my-project.side

You can pass capabilities to control the browser and environment:

selenium-side-runner \
 --capabilities "browserName=chrome" \
 --base-url "https://staging.example.com" \
 my-project.side

The --base-url flag is particularly useful because it lets you run the same .side file against different environments without editing the file. Point it at staging for daily CI runs and at production for post-deploy smoke tests.

For parallel execution:

selenium-side-runner --max-workers 4 my-project.side

This distributes test suites across four Chrome instances simultaneously, cutting run time proportionally for larger suites.

Best Practices for Reliable Tests

Recorded tests often fail due to brittle element selectors or timing issues. Follow these practices:

Use stable locators. Avoid dynamically-generated IDs. Prefer semantic attributes like data-testid or meaningful class names:

// Instead of:
css=#dynamic-id-48923
// Use:
css=[data-testid=login-submit]

Add explicit waits. Network delays cause flaky tests. Insert wait commands before assertions:

command: waitForElementVisible
target: id=dashboard
value: 5000

Keep tests independent. Each test should set up its own state. Avoid dependencies between tests that cause cascade failures. If test B depends on test A having run first, any failure in A silently invalidates B’s results without B actually failing on its own.

Name tests descriptively. Use meaningful names like test_login_with_valid_credentials rather than generic ones. In a test report with 200 failing tests, descriptive names are the difference between understanding the blast radius in five minutes versus an hour.

Review recordings before saving. Delete extra steps like accidental right-clicks, missed hovers, and redundant navigation. Lean recordings run faster and are easier to read months later when you are debugging an intermittent failure.

Group related tests into suites. Selenium IDE lets you organize tests into suites. Use this to separate smoke tests (fast, run on every commit) from regression suites (thorough, run nightly). The selenium-side-runner CLI lets you specify a suite name to run only that subset.

Limitations and When to Use Code

The Selenium IDE Chrome extension excels for quick prototypes and simple regression tests. However, it has real constraints that push complex automation toward hand-written code:

Scenario	Selenium IDE Suitable?	Recommended Alternative
Simple user flows (login, search, checkout)	Yes	.
Multi-tab workflows	Partial	Custom WebDriver script
File uploads	Limited	WebDriver with `send_keys` to file input
Data-driven tests (50+ test users)	No	pytest-parametrize or JUnit DataProvider
Visual regression testing	No	Percy, Applitools, or Playwright
API + UI combined tests	No	Custom test framework
Dynamic SPAs with heavy state	Difficult	Playwright or Cypress
OAuth / SSO flows	Difficult	Playwright with storage state

The IDE is not trying to replace Playwright or Cypress. It solves a specific problem: getting from zero to working test in under ten minutes. For that goal, nothing beats it. For everything else, use the export function as a head start and build from there.

Integrating Exported Tests into a CI Pipeline

Once you export tests to Python or Java, integrating them into GitHub Actions is straightforward:

.github/workflows/selenium-tests.yml
name: Selenium Tests
on: [push, pull_request]
jobs:
 test:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Set up Python
 uses: actions/setup-python@v5
 with:
 python-version: '3.12'
 - name: Install dependencies
 run: pip install selenium pytest
 - name: Install ChromeDriver
 uses: browser-actions/setup-chrome@v1
 - name: Run tests
 run: pytest tests/selenium/ -v --tb=short

The browser-actions/setup-chrome action handles matching ChromeDriver version to the installed Chrome version, which was historically the most common source of CI failures in Selenium projects.

Conclusion

The Chrome extension Selenium IDE recorder provides a fast path to browser automation without writing code. Record your interactions, export to your preferred language, and build a solid test suite from functional prototypes. Use it for rapid prototyping, simple regression coverage, and teaching test automation concepts to team members who are not yet fluent in WebDriver APIs.

For production environments, treat exported tests as a starting point. Apply the hardening patterns covered above. explicit waits, stable locators, proper teardown fixtures, and meaningful test names. Refactor into maintainable structures using page object patterns, explicit waits, and data-driven approaches as your suite grows beyond the handful-of-tests stage.

*

Try it: Paste your error into our Error Diagnostic for an instant fix.

I'm a solo developer in Vietnam. 50K Chrome extension users. $500K+ on Upwork. 5 Claude Max subscriptions running agent fleets in parallel. These are my actual CLAUDE.md templates, orchestration configs, and prompts. Not a course. Not theory. The files I copy into every project before I write a line of code. **[See what's inside →](https://zovo.one/lifetime?utm_source=ccg&utm_medium=cta-default&utm_campaign=chrome-extension-selenium-ide-recorder)** $99 once. Free forever. 47/500 founding spots left.