Playwright Cheatsheet
Quick reference guide for Playwright — Cross-browser end-to-end testing
Reviewed May 25, 2026. Privacy model: tool input is processed in your browser and is not uploaded to BytePane servers.
Quick answer
Playwright developer reference
Playwright is an end-to-end testing framework for modern web apps. Strong Playwright suites start with resilient locators, web-first assertions, isolated test data, traces on failure, browser projects, and a CI strategy that makes flakes visible instead of hiding them.
What to learn first
- •Prefer role, label, placeholder, text, and test-id locators over brittle CSS selectors.
- •Use web-first expect assertions so tests wait for UI state instead of sleeping.
- •Capture traces, screenshots, and videos on failure before debugging CI-only flakes.
Common pitfalls
- •Hard waits such as waitForTimeout make tests slower and usually more flaky.
- •Reusing one shared account across parallel tests can create state collisions.
- •Testing implementation details instead of user-visible behavior makes refactors painful.
Table of Contents
Locators are Playwright's resilience layer. A good locator describes what the user sees or interacts with, not the current DOM structure.
await page.getByRole("button", { name: "Sign in" }).click();
await page.getByLabel("Email").fill("[email protected]");
await page.getByTestId("checkout-submit").click();Key Concepts
- •Use role, label, placeholder, alt text, visible text, or test-id locators before CSS selectors.
- •Make test IDs stable product contracts when user-facing locators are not specific enough.
- •Avoid chaining through layout-only elements because redesigns should not break behavior tests.
Actions drive the page the way a user would. Playwright auto-waits for actionability, so most clicks and fills should not need manual sleeps.
await page.getByRole("textbox", { name: "Search" }).fill("jwt decoder");
await page.getByRole("button", { name: "Analyze" }).click();
await page.keyboard.press("Enter");Key Concepts
- •Let auto-waiting handle visibility, stability, and enabled state.
- •Use force only for rare cases where you intentionally bypass user-like behavior.
- •Pair actions with assertions so the test proves the state changed.
Web-first assertions wait for expected UI state. They make tests clearer and reduce timing races compared with reading a value once and asserting immediately.
await expect(page.getByRole("heading", { name: "Dashboard" })).toBeVisible();
await expect(page.getByText("Saved")).toBeVisible();
await expect(page).toHaveURL(/\/dashboard/);Key Concepts
- •Prefer await expect(locator).toBeVisible() to fixed timeouts.
- •Assert user-visible outcomes, not only network calls.
- •Use URL, text, count, attribute, and screenshot assertions deliberately.
Related Cheatsheets
About Playwright
Playwright is a e2e testing testing framework created by Microsoft in 2020. It is primarily used for cross-browser end-to-end testing. Playwright uses static typing, which catches type errors at compile time, improving code reliability and IDE support.
Why Use This Playwright Cheatsheet?
- ✓Quick Reference — Find syntax and patterns instantly without searching through documentation.
- ✓Organized by Topic — 10 sections covering all major Playwright concepts, from basics to advanced.
- ✓Source-Checked Notes — Highlights stable Playwright patterns, official documentation links, and production caveats reviewed for 2026.
- ✓Searchable — Use the search bar to jump to exactly the concept you need.
Getting Started with Playwright
Whether you're new to Playwright or an experienced developer looking for a quick reference, this cheatsheet covers the essential concepts you need. Start with the fundamentals like locators and actions (click, fill), then progress to more advanced topics like configuration and parallel testing.
Playwright has been widely adopted since its creation in 2020, with a strong community and ecosystem. Files typically use the .spec.ts extension. For the most comprehensive and up-to-date information, always refer to the official Playwright documentation alongside this cheatsheet.
Methodology & Sources for Playwright
How we compile Playwright cheatsheet content: Each entry is checked against official Playwright documentation, relevant specifications where available, and common production patterns. Examples are written to illustrate the concept clearly and should be verified against the exact version used in your project.
- Primary source: official Playwright documentation and language specification.
- Examples: reviewed for syntax shape and practical developer workflows.
- Use cases: selected from common production, documentation, and debugging scenarios.
- Common pitfalls: based on recurring implementation mistakes, docs caveats, and developer support patterns.
Authoritative sources:
- Stack Overflow — community Q&A reference
- MDN Web Docs (Mozilla) — open web standards
- W3C Standards — web platform specifications
- GitHub Open Source — implementation patterns
- NIST Computer Security Division — security best practices
- OWASP Security Standards — secure coding guidelines
Disclaimer: Cheatsheet content reflects standard usage patterns. Always verify with official documentation for your specific version. Code examples may need adaptation for your environment, dependencies, or framework version.
Reviewed by Brazora Monk · Last updated 2026
Standards, Specs & Security References for Playwright
For production code in Playwright, always verify against canonical specifications and security guidance — not just tutorials. Common runtime / language-version compatibility issues are addressed by:
Always cite the spec, not paraphrases:
- • W3C Standards (HTML/CSS)
- • ECMA-262 (JavaScript spec)
- • IETF RFCs (HTTP, JSON, base64, etc)
- • MDN Web Docs — practical reference
Avoid common vulnerabilities:
- • OWASP Top 10 — web security
- • OWASP Cheat Sheet Series
- • NIST SP 800 Series — security publications
- • MITRE CWE — Common Weakness Enumeration
Verify dependencies + audit:
- • npm Registry + `npm audit`
- • GitHub Security Advisories
- • NIST NVD (CVE Database)
- • Snyk Vulnerability DB
Modern toolchain references:
- • GitHub — Open Source Maintenance
- • Docker Documentation
- • Kubernetes Docs
- • Always pin versions in production lockfiles
ReDoS warning: Regex patterns with nested quantifiers can cause catastrophic backtracking. Test patterns with regex101.com and check OWASP ReDoS guidance before deploying user-input regex.
Frequently Asked Questions
What is Playwright used for?
Playwright is primarily used for cross-browser end-to-end testing. It was created by Microsoft in 2020. It follows the e2e testing paradigm.
Is Playwright hard to learn?
Playwright has a moderate learning curve. Start with the basics covered in sections like Locators and Actions (click, fill), then gradually work through more advanced topics. This cheatsheet helps by providing quick references for each concept.
How do I use this cheatsheet?
Use the search bar to find specific topics, click section headers to expand/collapse content, and use the table of contents for quick navigation. You can also expand or collapse all sections at once.