That is a request breakpoint: stop the request in flight, edit it, let it go. Desktop proxies have done this for twenty years, but they ask you to reroute your traffic and trust a certificate first. This guide shows how to do it from inside the page with tweak's Edit before send, which use cases it covers, and how it compares, feature and price, with Charles, Fiddler, Proxyman, Burp Suite and the free tools.

TL;DR​

• Edit before send pauses a matching fetch or XHR request on the page. You change the URL, body or headers, then press Continue request. You can also pause the response and rewrite it before your app reads it.
• No proxy, no certificate, no DevTools required. The editor opens over the page, in the tab you are working in.
• Edits are one-off. They never change the rule, so the next request behaves as saved.
• Price: $36 a year or $4 a month. That is 93% less than Burp Suite Professional, 75% less than Fiddler Everywhere Pro, and less than a Proxyman or Charles license in year one. Try it free for 7 days.

Why DevTools is not enough​

Most developers try the browser's own tools first, and hit the same wall:

None of them hold the real request your app is sending, let you change it, and hand the edited version back to your app's flow. That gap is why people go looking for "Tamper Data for Chrome", a Charles Proxy alternative, or an intercept tool like Burp.

How to set up Edit before send, step by step​

You need tweak installed and a Premium plan (the 7 day trial works).

1. Create a rule that matches the request​

Open tweak on the tab running your app and add a rule:

• URL: part of the request URL, for example /api/cart. Partial matching is the default, or switch on the regular expression toggle for something stricter. If request capture is on, the URL field suggests the requests the tab already made.
• Method: the HTTP method, for example POST.
• Rule type: Modify to edit real traffic that goes to your server. Mock if you want tweak to answer instead of the server (useful when the backend is down or not built yet).

Tip: if several requests share a URL (GraphQL, batch endpoints), narrow the rule with partial request payload matching so only the operation you care about pauses.

2. Choose where the rule should stop​

In the rule's debugging group, next to the breakpoint, open the Edit before send menu:

A small req, both or res caption under the icon reminds you the rule is armed.

3. Trigger the request and edit it​

Use your app as normal. When it sends a matching request, tweak holds it and opens an editor on the page itself, showing only the side that is paused. On a modify rule you edit the live request: the URL, body and headers that are about to go out.

4. Continue, or send it untouched​

• Continue request (Ctrl/⌘ + Enter): the request goes out with your edits.
• Send without edits: it goes out as the rule would have sent it.
• Cancel request: it never goes out. Your app sees it aborted (fetch rejects with an AbortError), a quick way to test that path too.

If several matching requests fire at once, they wait in line and the editor shows how many are queued.

5. Optional: rewrite the response before your app reads it​

With Pause the response (or both), the server's answer waits for you. Change the body, then Deliver response, Deliver without edits, or Cancel request.

6. Make it permanent, or switch it off​

Edits apply to that one request only. If you find yourself making the same edit every time, put it in the rule itself (the request payload tab, a request hook or a JavaScript snippet for the response) and turn Edit before send off.

Full reference: Edit before send docs.

9 things you can do with a paused request​

1. Test server side validation. Your form blocks a quantity of 99, a negative price or an expired coupon. The API should too. Pause the request, type the value the UI would never send, and see if the backend rejects it.
2. Check authorization on your own app. Swap the user, tenant or order id in the URL or body and confirm the server answers 403, not someone else's data.
3. Expire a session on demand. Edit the Authorization header to a stale token and watch how your refresh and logout flow behaves, without waiting an hour.
4. Try an API change before the backend ships it. Add the new field to the body and see what the current server does with it.
5. Reproduce a bug report. A customer sent a payload that broke something. Paste it into the paused request and hit the exact path again.
6. Design error states with real traffic. Pause the response and turn a 200 into the out of stock, rate limited or validation error your designer asked about.
7. Freeze a loading state. While a request is paused, your app is waiting on it. Skeletons, spinners and disabled buttons stay on screen as long as you need to inspect or screenshot them.
8. Debug third party calls. See exactly what an analytics, payment or chat widget sends from your page, and change one field to see how it reacts.
9. Stage a demo. Edit a response so the dashboard shows the numbers you want to present, then deliver it. Nothing on the server changes.

Use it on applications you own or are authorised to test.

Edit before send vs the alternatives​

Feature comparison​

The pattern is clear: desktop proxies see everything on your machine, and pay for it with setup. tweak sees what your web app sends, and needs nothing but the extension. If your bug lives in a browser tab, the second is the shorter path.

Price comparison​

List prices for the paid tier that includes breakpoints, as published in October 2026. Check each vendor's site before buying, prices move.

Two honest notes:

• Charles and Proxyman are one time purchases. Over several years without upgrades, Charles ends up cheaper than a tweak subscription. If you need system wide interception, that is a fair trade. If you only debug web apps, you are paying for a proxy you have to configure, and tweak's $4 month lets you pay for the one week you actually need it.
• Free tools exist. HTTP Toolkit's free tier includes request and response breakpoints, and Burp Suite Community, OWASP ZAP and mitmproxy intercept for free. They are proxies or separate apps, each with its own setup. Tamper Dev is a free extension that pauses requests, though its store reviews report it misses requests made by JavaScript. tweak's case is not "the only way", it is "the fastest way, in the browser you already use, alongside your mocks".

What about Requestly and ModHeader?​

Both rewrite traffic automatically from rules: set a header, redirect a URL, replace a response. That covers the "every time" case. We did not find an interactive pause and edit in either at the time of writing. tweak does both: rules for every time, Edit before send for just this once. Coming from ModHeader? See Goodbye ModHeader, hello tweak. Comparing with Requestly in general? See tweak vs Requestly.

Choosing the right tool for the job​

Start with your AI assistant​

These days, ask your AI tools first. They are breaking down the barriers between tools and stitching different workflows together, so if one of them can do the job for you, start there.

Sometimes they can't. Some jobs are runtime configuration of your environment, and they repeat on every page load:

• attaching certain request headers to every request in a browsing session (headers only rules)
• continuously redirecting a set of outbound HTTP requests to a different host (redirect rules)
• pausing the next matching request so you can change it by hand (Edit before send)

An AI assistant is not a good fit for that kind of work. You don't want to ask for the same header on every request; you want a rule that keeps applying it, in the browser, until you switch it off. That is the gap a focused tool fills.

When a desktop proxy is the better choice​

Pick Charles, Proxyman, Fiddler or Burp if:

• the traffic comes from a mobile app, a desktop app, a CLI or a backend service
• you need to pause page navigations, scripts, images or service worker requests (tweak pauses fetch and XHR, see known limitations)
• you are running a full security assessment with scanners, intruders and repeaters

When tweak is the better choice​

Pick tweak if the request comes from a web page and you want to change it now, without leaving the tab.

Every tool in this article is a good tool, and experts with different specialities reach for different ones to get different jobs done. What I'm saying is that in some cases you are better off with tweak, and you will save a lot of money doing it. Weigh which one best fits the problem you have, not the one with the longest feature list.

FAQ​

Try it​

Start the 7 day free trial, add a modify rule for the request you are debugging, set Edit before send to Pause the request, and trigger it. The next request is yours to change.

New to tweak? Start with the introduction. The free plan gives you 12 mock rules, no account required.

What happened​

ModHeader had a large install base built over years as a go-to tool for editing request and response headers. The code that got it pulled wasn't collecting data on day one, it was dormant, waiting. That's the part worth sitting with: an extension with broad host permissions can ship inert code today and activate it later, and most users would have no way to know until someone found it.

Header and network permissions are some of the most sensitive an extension can request. They see every request your browser makes: cookies, auth tokens, internal URLs, all of it. That access has to be earned with a track record, not just a good changelog.

Where tweak stands on header modification​

tweak has a dedicated headers only rule type built specifically for this job:

• Set, append, or remove any request or response header, including ones a page's own JavaScript is forbidden from touching, like Referer, Origin, and User-Agent.
• Reaches every request, not just fetch/XHR calls: page navigations, scripts, images, stylesheets, and fonts are all in scope.
• Two scopes: run it only on the active tab while tweak is on, or set it to Global so it persists across tabs and browser restarts, for the cases where you want an override simply always on.
• Matching uses the browser's own RE2 engine, so you get real regex matching without a hand-rolled parser trying to guess intent.

None of this runs through a proxy or a remote service. It's applied by the browser itself, tweak included, working entirely on your device.

How it actually looks​

Switch a rule to Headers only and you get a row per header, with a dropdown that picks the operation:

Each row can Set (replace the value, or add the header if it's missing), Append (add a value alongside the existing one, useful for a second Set-Cookie), or Remove (strip it out entirely):

Browsers only allow Append on a fixed allowlist of request headers (things like Accept, Cookie, User-Agent). Pick it on anything outside that list and the row tells you right there, instead of silently failing:

Below the header table, a Scope dropdown decides how far the rule reaches: Active tab applies it only while tweak is running, on the tab it's running on. Global applies it on every tab, whether or not tweak is running, and survives a browser restart, for the override you want simply always on:

That's the whole workflow: pick a header, pick an operation, pick a scope. No proxy setup, no certificate, no desktop app to install alongside it.

tweak is a free alternative to ModHeader for modifying both request and response headers. Every operation (Set, Append, Remove), on request and response headers, in both scopes, is on the free plan, with no account and no sign-up. The one paid part is templating, putting {{variables}} or generated values inside a header cell:

Profiles → Collections​

ModHeader's "Profiles" let you group header sets and switch between them. tweak's equivalent is Collections: folders that group your rules, not just headers only rules, so a collection can mix header rewrites with mocks and redirects if that's what a given workflow needs.

• Add a collection from the plus button in the side panel, drag to reorder, double-click to rename.
• Open collections show up as tabs in the main workspace, so you can flip between them the way you'd flip between profiles:

• A closed collection keeps working. While tweak runs, a green dot on its name in the side panel means it has active rules, even while the tab itself isn't open, no need to keep every profile "selected" to have it apply.
• Move rules between collections from a rule's own menu, and import/export either a single collection or everything at once.

We want to be upfront about this: Collections are a paid-plan feature. The free plan runs your 12 rules unorganized; grouping them into folders is part of Premium.

Our security posture is in the open​

• Manifest V3, and every permission maps to a capability the product visibly uses. No unused reach "for later."
• No server-side visibility into your rules, mocks, or traffic. They live in the browser's own storage APIs, on your device. Our servers only handle account sign-in, checkout, and license validation, they're not in the request path at all.
• Source is reviewed before every release. We don't ship code we haven't read, and dependencies are audited as part of that process.
• Vulnerability reports are welcome, not deflected: help@tweak-extension.com, with good-faith fixes and disclosure.

Full detail is on our security page.

Moving over​

If you're migrating header rules off ModHeader, tweak's headers only rule type covers set, append, and remove operations on both request and response headers, all of it free, with no account and no sign-up.

Try tweak free on Chrome or Edge. 12 rules on the free plan, no account required.

1. Rewrite headers without touching the body​

A dedicated Headers only rule type. Set, append, or remove request and response headers, on any tab or globally, without a mock response getting in the way. Flip a feature flag via a cookie, force a Cache-Control off, spoof X-Powered-By, all from one focused rule.

2. Redirect anything, not just API calls​

This one's been requested for a while: Redirect rules now catch images, stylesheets, scripts, whatever you point them at, not only XHR/fetch. Swap a CDN asset for a local file, send a whole API to localhost, or regex your way from v1 to v2 with a capture group.

3. A lighter, faster editor that follows you around​

The rule editor got a rebuild: snappier to open, snappier to type in. And it no longer has to live docked in DevTools. Pop it into a floating window from the menu and keep it on screen while you work anywhere else in the browser.

4. The fastest way to discover your application data (Beta)​

Crop-select any part of a page and Data X-Ray matches what you're looking at against the requests that produced it, badges every matching element, and lets you open, edit and import the payload as a tweak rule without leaving the page or digging through the Network panel.

Try it​

Two new rule types, a faster editor, and a first look at Data X-Ray: that's the bet behind v9.0.0. Update your extension and give it a try.

On Tweak Premium? All of this is unrestricted and already live in your extension, nothing to activate.

See what's new in v9.0.0

Browser extensions have been around for a while, making their way into our development workflow in many different shapes. We can think of extensions as development companions.

In this article, we would like to share a few of them that, in our opinion, provide valuable assistance for frontend developers.

Cookie-Editor​

tl;dr: Cookie manager. Create/update/delete cookies on any website
Users: 2M+
References: chrome web store | website

Cookie-Editor really feels productive due to its simple user experience. To access the application storage section, we often need to open the developer tools and perform a couple of clicks. Having the popup floating on top of the page just makes sense and feels more efficient. Modifying a specific cookie value becomes a quick task. Global actions are also available such as clearing all the site cookies.

JSONView​

tl;dr: Enhances your experience when visualizing JSON documents in the browser
Users: 900k+
References: chrome web store | website

JSON is undoubtedly one of the most used data formats on the web. Sometimes when inspecting REST API endpoints directly in the browser, it's beneficial to have a way to properly visualize JSON content. That's where JSONView comes in, providing a preview of JSON documents.

React Developer Tools​

tl;dr: Addon for React development. Tooling to inspect React components, their state, and component hierarchies
Users: 5M+
References: chrome web store

If you are a React developer, this tool is a must-have in your toolkit. It will make your life much easier when navigating through your application component tree, simultaneously allowing you to look up the current state of a given component, which is much more powerful than simply looking up a DOM element through the default HTML inspector. This tool is equipped with a profiler component, allowing you to tap into the performance of your React application.

Redux DevTools​

tl;dr: Inspect your Redux application state and how it changes throughout time
Users: 1M+
References: chrome web store | website

Much of the Redux library's success can be traced to the fantastic debuggability capabilities shipped within this extension. The Redux DevTools complements the library very well, powering the developer's decision to adopt Redux as a solution for state management. Just jump over to the "Reviews" section and be amazed by the unanimity gathered among so many developers.

Change Timezone (Time Shift)​

tl;dr: Change your default browser timezone
Users: 20K+
References: chrome web store

The tool description mentions privacy protection as a selling point to bring users on board. This extension is most useful for frontend developers when your application deals with timezone-specific logic/UI visualization. This means you no longer need to hack your way around globals or mess with the host/system time settings. Instead, let this extension work for you toggling different timezones on the fly; you'll be able to perform whatever validations you need in a quick and easily reversible way.

tweak​

tl;dr: Mock, modify, delay HTTP requests and much more!
Users: 50K+

The missing piece 😊  . tweak tackles a prevalent problem in web development: simulate data-driven UI behaviors. We've developed yet another mocking tool with a unique perspective to help you quickly tap into your HTTP requests and easily manipulate them, without writing code, in any environment. We put our best into providing a unique and quality user experience.

If you liked this article, consider sharing (tweeting) it to your followers.

Quick verdict​

What tweak does well​

Zero codebase changes. You don't need to install NPM packages, configure Webpack, or initialize service workers in your public directory. Install the extension, open the panel, and create a rule. You're intercepting requests within 60 seconds without writing a single line of code.

Testing in production. Because tweak sits at the browser level and doesn't require source code access, you can mock requests on live production sites. This is incredibly useful for reproducing bugs or testing edge cases on a deployed application where MSW is typically disabled.

Simple, visual UI. tweak is designed for immediate feedback. There's no need to write JavaScript resolvers or handle route matching syntax. You just use a clean interface with toggles and JSON editors to mock what you need and move on.

Accessible for non-developers. QAs, product managers, and designers can easily use tweak to simulate different application states (like an empty state or a 500 error) without needing to understand the underlying codebase or spin up a local development environment.

What MSW does well​

First-class automated testing. MSW is built to shine in your test suite. By intercepting requests at the network level in Node.js, it provides incredibly reliable mocks for tools like Jest, Vitest, and React Testing Library without patching your HTTP clients.

Single source of truth. With MSW, you write your mock handlers once and reuse them across your unit tests, integration tests, Storybook, and local development. This prevents the classic problem of having fragmented mock data across different testing tools.

Version controlled by default. Since MSW mocks are just code in your repository, they live alongside your application logic. When an API contract changes, the mocks are updated in the same pull request. Every developer on the team gets the exact same mock environment out of the box.

Framework agnostic. It intercepts requests below the client level, meaning it doesn't matter if your app uses Fetch, Axios, Apollo, or React Query. The same handlers work perfectly across the board.

Head-to-head: common scenarios​

"I need to quickly mock a 500 error to test a UI bug"​

Use tweak. No need to write an override handler or touch the code. Just open the extension, create a quick rule returning a 500 status, and refresh the page.

"I am writing an integration test in Jest"​

Use MSW. tweak only works in the browser. MSW's Node.js interceptors are practically the industry standard for intercepting requests during automated tests.

"I want the whole team to share the exact same mock data"​

Use MSW. Because handlers are committed to Git, your team is always on the same page. While tweak allows you to export and share rules manually, MSW makes sharing implicit and automatic.

"I'm testing an issue on our live staging environment"​

Use tweak. MSW is almost always stripped out of production and staging builds for performance and security reasons. tweak works perfectly on live URLs since it operates via the browser extension sandbox.

"I need to mock responses for a backend API that isn't built yet"​

Either works. If you're a solo developer working quickly in the browser, tweak is faster. If you're establishing the foundation for a project that will eventually need automated tests anyway, setting up MSW early is a smart investment.

Pricing compared​

tweak is free for up to 12 rules with no account required. Premium is $36/year (billed annually) or $4/month, granting unlimited rules and advanced matching capabilities.

MSW is completely free and open-source (MIT License). There are no paid tiers or limits on rules.

When to use each tool​

Choose tweak if:

• You want to mock requests immediately without touching application code.
• You need to intercept requests on deployed environments (staging/production).
• You're a manual QA, designer, or PM who isn't working directly in the codebase.
• You value a visual interface over writing mock definitions in code.

Choose MSW if:

• You are setting up an automated testing suite (Jest, Vitest, Cypress).
• You want a single source of truth for mock data across your entire project.
• You need mock definitions to be version-controlled in Git.
• You are building a complex application where development and testing share the same network mocks.

The bottom line​

tweak and MSW are not mutually exclusive; in fact, they are highly complementary. tweak is optimised for speed, manual testing, and immediate visual feedback in the browser. MSW is the definitive tool for code-driven API mocking and automated testing.

Most modern frontend teams benefit from using both: MSW to power robust automated tests and provide baseline development mocks, and tweak for rapid exploratory testing, edge-case simulation, and debugging live environments without code changes.

Try tweak free. No account required, 12 rules on the free plan.

If you liked this article, consider sharing (tweeting) it to your followers.

Quick verdict​

What tweak does well​

Zero friction to start. Install the extension, open the panel, create a rule. No account, no proxy configuration, no certificate installation. You're intercepting requests within 60 seconds.

Simple, focused UI. tweak does one thing exceptionally well: intercept and modify HTTP requests in the browser. The interface is lean and intentional. There's no dashboard overload, no learning curve, just rules and toggles.

Free tier that's actually useful. The free plan includes 12 mock rules with no account required. For solo developers and debugging workflows, that's genuinely sufficient for real work.

Browser-native, no system overhead. tweak runs entirely inside your browser extension sandbox. There's no proxy to configure, no certificate to install, no system-level meddling. It works in your existing browser session with zero external dependencies.

Cross-browser compatibility. Works natively in Chrome, Edge, and Firefox. Install once, use everywhere.

What Proxyman does well​

System-wide traffic interception. Proxyman is a desktop proxy that can intercept traffic from any application on your machine, not just browsers. Desktop apps, mobile devices, command-line tools, servers: if it makes HTTP requests, Proxyman can see it and modify it.

Mobile debugging powerhouse. Proxyman has first-class support for iOS and Android debugging. Forward your mobile device traffic through Proxyman's proxy to inspect and mock network calls from your apps in real time. This is invaluable if you're building mobile applications.

Deep HTTP inspection. Proxyman gives you granular control over every aspect of requests and responses: headers, cookies, timing, SSL/TLS details, and more. If you need forensic-level visibility into network behavior, Proxyman delivers.

All browsers and tools. Since Proxyman works at the system proxy level, it works with Chrome, Safari, Firefox, Edge, curl, Postman, and any other HTTP client on your machine.

Breakpoints and request modification. Pause requests in flight, inspect them, and modify them before they're sent. Useful for complex debugging scenarios where you need to intercept at specific points.

Head-to-head: common scenarios​

"I need to mock an API endpoint quickly during development"​

Use tweak. No setup, no account, no proxy hassle. Create a rule and test immediately.

"I need to debug a mobile app's API calls"​

Use Proxyman. tweak is browser-only. Proxyman's mobile debugging capabilities are built for exactly this use case.

"I need to intercept traffic from a desktop application"​

Use Proxyman. tweak doesn't work outside the browser. Proxyman's system proxy handles any application.

"I need to test error states and edge cases in the browser"​

Either works. Both tools can mock responses and override status codes. tweak is faster to set up; Proxyman offers more granular control if you need it.

"I'm debugging in multiple tools (browser, mobile, desktop app, backend)"​

Use Proxyman. Proxyman covers all of these. tweak is limited to browser contexts.

"I want something lightweight that doesn't slow down my machine"​

Use tweak. It's a browser extension with minimal overhead. Proxyman, as a system proxy, uses more resources and can impact performance if poorly configured.

"I'm solo, working in the browser, and want zero friction"​

Use tweak. Free tier, no account, no configuration. You're done in seconds.

Pricing compared​

tweak is free for up to 12 rules with no account required. Premium is $36/year (billed annually) or $4/month, with a 7-day free trial.

Proxyman is free with some limitations (history and rule limits). Paid plans are around $99/year per person, with slightly higher pricing for teams.

For solo developers working primarily in the browser, tweak is significantly cheaper. For teams or developers who need system-wide proxy capabilities, Proxyman's pricing aligns with its broader feature set.

When to use each tool​

Choose tweak if:

• You work primarily in the browser
• You want to start mocking requests immediately with zero setup
• You're a solo developer or small team
• You value simplicity and lightweight tooling
• You need cross-browser compatibility without fiddling with system proxies

Choose Proxyman if:

• You need to debug mobile apps (iOS/Android)
• You need to intercept traffic from any application on your machine
• You need system-wide proxy capabilities
• You're doing deep HTTP forensics or performance analysis
• You're working in a team environment with diverse debugging needs

The bottom line​

tweak and Proxyman serve different use cases. tweak is optimised for speed and simplicity in the browser; Proxyman is a comprehensive proxy solution for anyone who needs visibility into system-wide network traffic.

If your work stays in the browser, tweak is the faster, simpler, cheaper choice. If you're debugging mobile apps, desktop applications, or need system-wide interception, Proxyman is worth the investment.

Most developers benefit from having both: tweak for quick browser-based debugging, and Proxyman for the occasions when you need deeper system-level visibility.

Try tweak free. No account required, 12 rules on the free plan.

Quick verdict​

What tweak does well​

Zero friction to start. Install the extension, open the panel, create a rule. No account, no sign-up flow, no onboarding wizard. You're mocking requests within 60 seconds of installing.

Simple, focused UI. tweak does one thing: intercept and modify HTTP requests. The interface reflects that. You see your rules, you toggle them on and off, you're done. There's no feature sprawl to navigate.

Free tier that's actually useful. The free plan gives you 12 mock rules with no account required. For most solo development and debugging workflows, that's enough to get real work done.

Browser-native, no proxy. tweak runs entirely in the browser. There's no proxy to configure, no certificate to install, no system-level setup. It works in your existing browser session with your existing cookies and headers intact.

What Requestly does well​

Desktop app. Requestly has a standalone desktop application that can intercept system-wide traffic, not just browser requests. If you need to mock requests from a mobile app or a non-browser client, Requestly can handle that.

Team collaboration. Requestly has built-in support for sharing rule sets across a team, which is valuable in larger engineering organisations where mock configurations need to be consistent across developers.

More rule types. Requestly supports a wider range of rule types including script injection, response delays at the rule level, and more granular redirect logic. If your mocking requirements are complex, Requestly's breadth may be a better fit.

Safari support. Requestly supports Safari in addition to Chrome, Firefox, and Edge. If you need to test on Safari specifically, that's a deciding factor.

Head-to-head: common scenarios​

"I need to mock an API endpoint quickly during development or quick live production testing"​

Use tweak. No account, no configuration overhead. Create a rule, set the response, move on.

"I need to share mock rules with my whole frontend team"​

Use Requestly. Its team sharing features are built for this. tweak's sharing story is limited to exporting/importing rule files manually.

"I need to mock requests from a React Native app"​

Use Requestly. tweak is a browser extension; it only works inside a browser. Requestly's desktop proxy can intercept traffic from any client.

"I need to test a specific error state or edge case without changing the backend"​

Either works. Both tools handle response mocking, status code overrides, and header modification. tweak's UI is faster to reach for a one-off test; Requestly is better if the rule will live long-term in a shared workspace.

"I'm a solo developer and just want something that works"​

Use tweak. The free tier, the zero-sign-up experience, and the focused interface make it the lower-friction choice for individual developers.

Pricing compared​

tweak is free for up to 12 rules with no account. Premium is $36/year (billed annually) or $4/month, with a 7-day free trial.

Requestly has a free tier that requires account creation. Paid plans start at around $9/month per user, with team plans priced higher.

For solo developers, tweak's annual plan is meaningfully cheaper. For teams already paying for Requestly's collaboration features, the cost calculus changes.

The bottom line​

Choose tweak if:

• You want to start mocking immediately with no account
• You're a solo developer or work mostly independently
• You value a clean, minimal interface
• Browser-only interception covers your use case

Choose Requestly if:

• You need to share rules across a team
• You need to intercept non-browser traffic (desktop app, mobile)
• You need Safari support
• You require more advanced rule types

Neither tool is strictly better. They serve different points on the complexity spectrum. tweak optimises for speed and simplicity; Requestly optimises for breadth and team use.

Try tweak free. No account required, 12 rules on the free plan.

The numbers that matter​

54 million requests intercepted across 83,971 users. That's a lot of HTTP traffic being tweaked, modified, and debugged by actual humans doing actual work.

Most users keep it simple: 6 rules or less. But there's a fascinating tail of a few hundred power users configuring 100+ rules. We have no idea who they are, because that's how anonymous tracking is supposed to work 😊. What are they building? Enterprise test environments? Elaborate API mocking setups? We don't know, but we're impressed.

What we've learned​

Feature complexity doesn't drive conversion. We built sophisticated functionality: breakpoints, logpoints, mock generation and auto-enabled sites. Usage is negligible. Meanwhile, simple request modification continues to dominate.

The 6-rule threshold is real. There's a massive drop-off after 6 rules. This suggests most use cases are relatively simple: override an API endpoint, inject test data, modify some headers. Done.

The AI question​

Will AI agents replace tweak in two years? Probably not entirely. Here's why:

AI is great at generating code, answering questions, even writing API mocks. But intercepting and modifying live HTTP traffic requires precision, not probability. You need to know exactly which request to catch, exactly what to change, and exactly when it fires. In addition to that, you probably won't want an AI agent poking around your live API traffic without strict controls.

That said, AI could make our UI obsolete. "Intercept all requests to /api/users and add an Authorization header": that's a perfect AI prompt. The question isn't whether AI replaces HTTP interception, but whether it replaces our configuration interface (this is not just true for tweak of course).

What's next​

We're not pivoting to AI (everyone else already is). We're going back to basics:

1. Double down on the core: Request modification works. Make it bulletproof, address edge cases and customer pain points.
2. Explore GraphQL tooling: The signal is weak but consistent. GraphQL has made it, it has become a boring technology. Maybe there's something there.
3. Rethink paid features: Complex features don't convert. What would?

54 million requests intercepted. 83,971 users trusting us with their HTTP traffic. Not obsolete yet.

See you in 2026, if we're still here.

Want to help us not get obsoleted? Try tweak and tell us what actually matters to you. We're clearly bad at guessing.

If you liked this article, consider sharing (tweeting) it to your followers.

It's possible to pin a Chrome extension in the Chrome browser simply following the steps:

1. Open the Chrome browser.
2. Click on the "puzzle piece" icon in the top right corner of the browser.
3. Locate the extension you want to pin.
4. Click on the "pin" icon next to the extension you want to pin.

Below an imagine and a short clip to illustrate the steps.

Here's a short clip, demonstrating it pinning the tweak chrome extension in this case.

And here are the key UI key points to pin an extension.

If you liked this article, consider sharing (tweeting) it to your followers.

• Breaking Barriers: For the first time, we smashed the 50k weekly active users mark, growing from 30k to 50k, a massive +65% increase!
• Browsers in Action: Tweak users span across Chrome, Firefox, and Edge. Unsurprisingly, Chrome leads the pack with 94% of users choosing it for Tweak.
• Power Users:
  • 4.6k users intercepted 1k+ requests, 4x more than in 2023!
  • Over 500 users intercepted 10k+ requests, 6x more than last year.
  • 20+ users hit the incredible milestone of 100k+ intercepted requests, growing by +40% YoY.
• Rule Creators Unite:
  • Our users crafted a whopping 248,406 tweak rules this year.
  • Over 400 users created 100+ rules, showing just how engaged and creative our community is.
• Intercepting at Scale: Together, you intercepted 48.6M requests this year, +38% YoY, breaking that down to 133k requests every single day!

None of this would be possible without you. As we head into 2025, we’re excited to continue growing, innovating, and helping you maximize your development and testing productivity.

Here’s to another year of tweaking the web, together! 🎉

Purpose​

Developers leverage HAR files primarily for performance analysis and debugging. When a user reports slow page load times or unexpected behavior on a website, developers can use HAR files to trace the issue back to its source. The file captures a comprehensive log of all network requests and responses, including details such as URLs, headers, and timings. This enables developers to pinpoint bottlenecks, identify inefficient resource loading, and optimize the overall performance of a web page.

Advantages (why use them?)​

The adoption of HAR files is widespread due to several key advantages. Firstly, HAR files offer a standardized, platform-independent format. This means developers can share and analyze these files across different tools and environments, streamlining collaboration and issue resolution. Secondly, HAR files provide a granular level of detail. Developers can scrutinize each HTTP request, enabling them to detect issues like slow server responses, unnecessary redirects, or large resource files that contribute to sluggish page loads.

Moreover, HAR files are not limited to capturing just the technical aspects of web interactions. They also include timing information, allowing developers to understand the chronological sequence of network events. This is crucial for diagnosing problems related to rendering delays or asynchronous resource loading.

Inside HAR Files​

A typical HAR file includes a variety of information, organized into key sections. The "log" section encapsulates the overall structure of the file, containing details about the creator, browser, and the start and end times of the recording. The "entries" section is the heart of the HAR file, documenting each individual HTTP request and its corresponding response. For every entry, developers can inspect headers, timings, and content, gaining insights into the performance characteristics of each resource fetched.

Additionally, the "pages" section provides a high-level overview of the loaded pages, and the "browser" section offers information about the browser's version and capabilities during the recording. Altogether, the information within a HAR file forms a comprehensive record of a user's interaction with a website, empowering developers to analyze and optimize every aspect of web performance.

Conclusion​

In conclusion, HAR files serve as invaluable tools for developers seeking to enhance the performance and user experience of web applications. They offer a standardized, detailed record of network interactions, enabling efficient collaboration and issue resolution. From identifying bottlenecks to optimizing resource loading, HAR files provide a comprehensive view of a website's behavior. They are widely adopted mainly due to their effectiveness in streamlining the development and debugging processes, making them an indispensable asset in the toolkit of web developers.

With tweak you can easily import HAR files and convert them into tweak rules which allow you to quickly simulate the network conditions captured in the HAR file. This is particularly useful for testing and debugging purposes, as you can replicate specific scenarios and analyze how your web application behaves.

If you liked this article, consider sharing (tweeting) it to your followers.

1. Create the rule with an appropriate URL expression​

Through the use of regular expressions (toggling the .* button) or through a catch-all partial URL rule you are able to target your desired URL without specificying all the nitty gritty details of the URL such as the query parameters or entity identifiers. Here's an example where we'll grab all the GET requests for "Game of Thrones" characters without specifying their identifier in the URL.

2. Use a modify rule with a request hook​

Toggle the rule to Modify. Modify rules will allow you to manipulate the URL using JavaScript as we'll see next. Click the Request hook editor tab and write the code to manipulate the URL.

// Grab string after ?.
const urlParams = new URLSearchParams(url.split('?')[1]);

// If "continent" param is preset override its value.
if (urlParams.has('continent')) {
  urlParams.set('continent', 'weOverrideContinentWithThisValue');
}

const finalUrl = `${url.split('?')[0]}?${urlParams.toString()}`;

return {
  method,
  // Don't forget to return the modified URL here.
  url: finalUrl,
  body,
  headers,
};

3. Trigger the request again with the rule active​

As show in the above screenshot triggering the request again after activating your modify rule actives overrides the query parameter with your desired value. That's all ✅.

What else can you do?​

There's really no limit, here's some ideas:

• Modify the URL entirely, e.g. forward the request to some other server or endpoint.
• Generate random query parameters using JavaScript to fullfill a myriad of testing use cases.
• Use console.tables to print a structured view of the URL query parameters.
• Write your own generic script that can modify any URL query parameters given an object with key value pairs (query param, query param value) 🚀

And so much more. It's really up to you how you leverage the power of request hooks. If you're finding this pattern useful there's a very high change that you'll find response hooks just as useful.

If you liked this article, consider sharing (tweeting) it to your followers.

Unleashing the Power of Mocking in Microsoft Edge​

Our customizable API mock server extension, aptly named "tweak," brings unparalleled convenience to developers working in the Microsoft Edge Browser. By seamlessly integrating into your browser environment, tweak eliminates the need for external tools or complex server setups, allowing you to mock HTTP requests directly within your development workflow.

Overwhelming amount of requests​

We were not expecting to receive so many requests to have the extension available in the Microsoft Edge store, but it seems to match the recent increase in adoption of the Microsoft browser.

If you liked this article, consider sharing (tweeting) it to your followers.

From playful successes to mysterious redirects, and from sassy client errors to menacing server mishaps, let's dive into the fun and fascinating world of HTTP status codes!

Cracking the Code: Different Groups, Different Semantics​

HTTP status codes are divided into groups based on their first digit. Each group carries its own set of semantics, giving us clues about what's happening behind the scenes. Let's take a look at the four main groups. Let's dive in.

2xx Success: "You Rock!"​

These status codes (aka the success codes) indicate that your request was successful, and everything is fine. It's the web's way of giving you a high-five for a job well done. Here are a few of the coolest members of this group:

3xx Redirection: "Follow the Rabbit Hole"​

When you encounter these codes, the web is guiding you through the labyrinth. It's like following a trail of breadcrumbs, hoping to find what you're looking for. Here are a few notable codes from the redirection group:

4xx Client Errors: "Whoopsie-daisy! It's Your Fault"​

These error codes occur when the client sends a malformed request. What does it mean "malformed" anyways? A simple exmaple is when sending invalid parameters in the URL, e.g. the API expects a number but you send text. The web can get a little sassy here, playfully nudging you to correct your mistakes. Beware of these amusingly troublesome codes:

5xx Server Errors: "Houston, We Have a Problem"​

When the server experiences internal difficulties, it politely informs you with these error codes. It's like the web's way of saying, "Oops, my bad. Something went wrong on my end.". Here are a few dramatic codes from the server error group:

The Pitfalls of Misinterpreting Semantics​

Misunderstanding or misusing HTTP status codes can lead to some hilarious yet frustrating situations. Here are a couple of common pitfalls to avoid:

• Expecting the Unexpected: Assume you're expecting a 200 "OK" response, but you receive a 404 "Not Found" instead. You might find yourself scratching your head, wondering if the internet has gone haywire. Double-check your URLs and ensure you're sending the right requests.
• Chasing Redirections: You're following a series of 302 "Found" redirects, feeling like Alice in Wonderland, only to discover that the resource you're looking for has moved permanently.

Client-Side Gotchas: Watch Out!​

When working with HTTP status codes, client-side surprises can sometimes catch you off guard. Here are a couple of quirky situations to keep an eye out for:

• Caching Conundrums: The browser caches responses, which can lead to confusion. You make a request, but instead of fetching fresh data, the browser serves up a stale 304 "Not Modified" response. Clear your cache or use cache-busting techniques to ensure you're getting the latest and greatest.
• Permission Predicaments: You're trying to access a resource, but you receive a 403 "Forbidden" response, leaving you feeling like an unwelcome guest. Double-check your credentials, permissions, or any necessary authentication tokens to access the desired resource.

Note about real life​

While HTTP status codes provide a structured way of communicating between clients and servers, it's important to remember that they are ultimately just guidelines. It's up to developers to ensure their implementations align with the standard semantics. Occasionally, you might encounter situations where a server error is disguised as a 200 "OK" response. This can happen when developers mishandle errors or fail to properly adhere to the expected conventions.

Wrapping Up the Adventure​

Congratulations! You've ventured through the whimsical world of HTTP status codes. We hope this playful guide has shed some light on HTTP status codes!

If you liked this article, consider sharing (tweeting) it to your followers.

Content-Type​

The Content-Type header specifies the MIME type (Multipurpose Internet Mail Extensions) of the content being sent or received. It informs the recipient about the format and structure of the data, allowing it to be processed correctly. For example, "Content-Type: text/html" indicates that the content is HTML, while "Content-Type: application/json" signifies JSON data.

Use case​

Properly setting the Content-Type header ensures that the client understands how to interpret and render the received content, avoiding parsing errors or misinterpretation.

User-Agent​

The User-Agent header identifies the client application or user agent (e.g., web browser, crawler, or API client) making the request. It provides details about the software and version, operating system, and device used by the client.

Use case​

Web servers utilize the User-Agent header to determine the capabilities of the client, enabling server-side optimizations and customization based on the client's characteristics. Are you getting unwanted traffic in your servers? Well, the User-Agent might be a good hint often indicating the presence of bots! 🤖

Accept​

The Accept header specifies the media types or content types that the client can handle or prefers in the response. It allows the client to communicate its preference regarding the format of the response data.

Use case​

Servers can analyze the Accept header to choose an appropriate response format when multiple options are available. For example, if the Accept header contains "application/json", the server may respond with JSON data rather than XML or HTML.

Authorization​

The Authorization header carries credentials or tokens required for authentication purposes. It is used to provide proof of identity and permissions to access protected resources.

Use case​

When making requests to restricted areas or performing actions that require authentication; the Authorization header holds the necessary information to validate the client's identity.

Cache-Control​

The Cache-Control header controls caching behavior for both the client and intermediary servers. It specifies directives to define caching rules, such as caching duration, cache validation, or disabling caching altogether.

Use case​

Caching improves performance and reduces the load on servers. By setting appropriate Cache-Control directives, developers can optimize how content is cached and delivered to clients, improving page load times and reducing bandwidth usage.

Conclusion​

HTTP headers are integral components of web communication, facilitating effective data exchange between clients and servers. By understanding the meaning and use cases of common HTTP headers like the ones above ☝️, developers can enhance their web applications' functionality, security, and performance.

If you liked this article, consider sharing (tweeting) it to your followers.

Motivation​

HTTP headers let the client and the server pass additional information with an HTTP request or response. This meta-information is important for a website’s functionality and security. Until now, editing HTTP headers required having access to the actual web server, which often made it difficult to quickly experiment with changes to HTTP headers.

[source: ChromeDevTools/rfcs]

Overriding a response header is a developer need that is tipically related with the following use cases:

1. Debugging and troubleshooting: modifying response headers helps developers debug and troubleshoot issues by simulating different server behaviors.
2. API testing and development: developers can test and handle various API responses by modifying response headers in the browser.
3. Caching and performance optimization: modifying response headers allows developers to experiment with caching configurations and optimize frontend performance.
4. Security: response header modification helps verify security measures and test authentication mechanisms.
5. API versioning and compatibility: developers can ensure API compatibility by modifying headers and testing different API versions.

How​

The Chrome team made it very simple this time. Here's how you can add or modify response headers:

1. Open the devtools panel in the Network tab.
2. Locate and open the request you wish to modify the response headers.
3. Locate the Response Headers in the Headers panel.
4. You'll see that the UI looks a little bit different from usual:
   1. You can click + Add header to add a new response header.
   2. You can edit existing reponse header values.

Once you trigger the same request again your modifications are applied to the response header(s) as you can see in the highlighted sections in the screenshot above.

That's it!

Limitations​

For simple modifications the Chrome Network Panel has you covered. However if you find yourself bumping into these limitations:

1. You need to easily restore overrides without having to manage chrome override files.
2. You need to also modify request headers in a similar fashion.
3. You need to programatically change headers (say with custom JavaScript code?).

You came to the right place, please read on!

Beyond browser developer tools​

Altough Chrome will cover most of your basic needs, if you're hitting on the above limitations, you can try tweak whenever you're ready.

Modify request headers​

With an intuitive table like interface you modify both request and response headers.

Programatically modify request headers​

With request hooks you can write your own custom script that modifies the specificied headers only when the request meets some criteria; for example when the URL or request body have specific keywords or content.

If you liked this article, consider sharing (tweeting) it to your followers.

One of the key benefits of keyboard shortcuts is that they allow developers to quickly access and use the various debugging tools that are built into modern browsers. For example, in Chrome, developers can use the shortcut CTRL + SHIFT + I (CMD on Mac) to open the Developer Tools window, which provides a range of tools for inspecting and debugging web pages. This shortcut is much faster than using the mouse to click on the Developer Tools icon in the browser's toolbar.

Another great example is the use of CTRL + SHIFT + C to enter Inspect Element mode, which allows them to click on any element on a web page and see its HTML and CSS code. This can be very useful for quickly identifying and fixing problems with the layout or styling of a web page.

If you're curious about particular keyboard shortucts for web development, here are 10 Must Known Chrome Keyboard Shortcuts.

Why should I care?​

tl;dr

1. Efficiency.
2. Accuracy.
3. Accessibility.

Let's expand on these:

1. They can help speed up common tasks and improve efficiency in the development process.
2. Keyboard shortcuts can also help to improve accuracy and precision in the development process. By using the keyboard to navigate and interact with the development tools, developers can avoid the potential for errors that can occur when using a mouse or trackpad, such as accidentally clicking the wrong element or button
3. By using shortcuts you are contributing to the overall improvement of web applications. By using keyboard shortcuts to navigate and interact with web pages, developers can ensure that their applications are accessible and usable by users who may not be able to use a mouse or trackpad, such as those with motor impairments or users who prefer to use a keyboard

Tips for memorizing shortcuts​

Ultimately, the key to memorizing keyboard shortcuts is to make a conscious effort to use them regularly.

Another helpful tip is to customize the keyboard shortcuts to match the developer's individual preferences and workstyle. Most tools nowadays support this.

Conclusion​

Overall, keyboard shortcuts are an invaluable tool for web developers, as they can help speed up common tasks and improve efficiency in the development process. By learning and using these shortcuts, developers can save time and streamline their workflow, allowing them to focus on the important work of creating great web applications.

If you liked this article, consider sharing (tweeting) it to your followers.

Demystifying mocking​

The term "mock" comes from the verb "to mock," which means to imitate or copy something in a teasing or derisive manner.

Mocks, or mock objects, are often referred to as "fake" because they are not the real thing. In testing, a mock is a simulated version of a real object or service, such as a database or a network connection. It is called a mock because it is not the real thing, but it behaves similarly and can be used to test the code without relying on the actual object or service.

In the context of testing, mocking is a way of imitating the behavior of a real object or service in a controlled and predictable way so that the code can be tested without relying on the real thing. So when developers refer to mocks as "fake" data, they use the term to indicate that the data is not real but is being used as a stand-in for testing purposes.

Mocking in web development?​

In the context of web development, mocking is a common practice because it allows them to test their code without making real network requests. This can be useful for various reasons, such as testing how the code handles different response data types or simulating error conditions that would be difficult or impossible to reproduce in a live environment. One way to mock HTTP requests in JavaScript is to use a library like nock or sinon.js. These libraries provide a fake implementation of the XMLHttpRequest object, which is the object that JavaScript uses to make network requests. By using a fake XMLHttpRequest object, you can control exactly what data the code receives when it makes a request, which makes it much easier to test different scenarios.

Disadvantages of mocking​

One disadvantage of mocking HTTP requests is that it can make your tests less realistic. Since you are not actually making a real network request, your tests may not accurately reflect how the code will behave in a production environment. This can make it more difficult to catch bugs or other issues that only arise when the code is running in a real-world production environment.

Another disadvantage is that mocking HTTP requests can complicate your tests. Since you are not actually making a real network request, you have to manually set up all of the data that the code would receive in a real request. This can take a significant amount of time and effort, and it can make your tests more difficult to read and maintain.

Conclusion​

While mocking HTTP requests can be a helpful tool, it is essential to use it wisely and only when necessary. Sometimes, it may be better to make an actual network request and use techniques like stubbing or faking to control the response data. This can provide a more realistic and efficient testing environment.

However, sometimes, it is handy to use mocking across any environment, for example, to debug an issue in production. With our browser extension tweak you can achieve all of this without worrying about the implementation details and the maintainability burden they pose for you and your team. Furthermore, you can use the tool seamlessly for testing across any environment, from local development to production.

If you liked this article, consider sharing (tweeting) it to your followers.

1. Our experience - we tried six different frameworks by writing the same test case on the same web application and provided detailed pros/cons of working with those technologies. All the code examples are available here.
2. Deep dive - to help you decide the best framework for your project, we pulled together many different data sources - e.g., the state of JS survey, social networks, GitHub, etc. We evaluate each framework across four categories: feature set, adoption & popularity, DX (developer experience), and maintenance.

The frameworks​

Let's start by briefly exploring the background of the chosen frameworks. We're listing our picks in alphabetical order.

• Cypress - created by Brian Mann, was opened to the world in 2017. Cypress became more than a framework. Besides the core library with APIs to write tests, Cypress expanded into a platform that offers a complete overview of the test's performance, presenting an all-in-one monitoring dashboard.
• Nightwatch.js - initially released under a company called pineview.io, now Nighwatch.js belongs to BrowserStack, with Andrei Rusu, creator of Nightwatch.js, still contributing actively to the project. With a relatively small API, Nighwatch.js focus on essentials (e.g., integrated runner, assert API).
• Playwright - backed by Microsoft, with initial developments led by Pavel Feldman and Andrey Lushnikov, Playwright wants to come across as a resilient, robust, and unified tool to run E2E tests against any browser (Opera and Safari included). Playwright goes beyond the JavaScript ecosystem offering support for additional programming languages.
• Protractor 🎖(honorable mention) - we're not going to look into Protractor due to its narrow focus on Angular applications. Regardless, we want to mention this pioneer open-source technology that played its role in the history of JavaScript.
• Puppeteer - backed by Google, Puppeteer had its initial development primarily led by Andrey Lushnikov, who now works on Playwright. The first thing to note is that Puppeteer is a library and not a framework; hence many of the features you would expect to find in a testing framework are not present, such as assert API.
• TestCafe - backed by DevExpress, this framework has good cross-browser support and a simple yet rich testing API. Like Cypress, TestCafe expands into a platform, TestCafe Studio.
• Webdriver.io - with Christian Bromann as lead maintainer, this framework had a major rewrite in 2021 (v7 release), which reassured its presence amongst other frameworks in this list. The main selling point of Webdriver.io is interoperability. Webdriver.io allows developers to test native mobile applications (iOS and Android), stretching beyond the scope of web application testing.

🧪 Our experience​

This section documents our journey while setting up and writing one test with every framework. A hands-on experience with each technology will help us interpret the community trends, which we'll cover later in this article.

Test use case​

We've built a simple react application that contains a heading element, a button, and a paragraph. When clicking the button, we trigger an ajax request and display a quote on the screen.

It's time to see some code! We'll go through the frameworks in alphabetical order. For each framework, we'll list items we've liked and disliked.

Cypress​

Cypress has detailed documentation about its APIs and contains guides/articles with recommendations and good testing practices.

const selectors = require('./common/selectors');
const mock = require('./common/mock');

it('Cypress', () => {
  cy.intercept('/random-quote', mock).as('getRandomQuotes');
  cy.visit('http://localhost:3000/');
  cy.get(selectors.title).should('have.text', 'Quotez');
  cy.get(selectors.contentEmpty).should('be.visible');
  cy.get(selectors.contentEmpty).should('have.text', '...');
  cy.get(selectors.trigger).click();
  cy.get(selectors.content).should('have.text', `${mock.quote} by ${mock.author}`);
});

👎 Disliked​

• We faced overwhelming documentation during onboarding; we felt pulled in many different directions. Onboarding should be a smooth user journey where one learns to use the basics of the framework.
• Cypress is highly opinionated about scaffolding. On the other hand, everything is configurable, so you need to dig through the docs to figure out how to configure the project according to your preference.
• Cypress has a list of trade-offs that might be a deal-breaker for many projects. It's noteworthy that the Cypress team is transparent about this.

👍 Liked​

• The automated onboarding generates quite some files, but all in all, it's fantastic.
• Cypress refreshes the browser as you update your test files, offering a seamless developer experience.
• Cypress has a beautiful API design that is easy to understand (navigation, selectors, mocking). It took seconds to intercept a request and provide mock data.

  cy.intercept('/random-quote', mock).as('getRandomQuotes');
  

• Intellisense works remarkably well even on JavaScript-only projects, where you get autocompletion for should statements such as 'have.text' or 'be.visible'.
• The time-traveling debugging is a few miles ahead of the competitors, making debugging much more convenient.
• Our test has only 12 LOC, making it the shortest test we've written during our experiments.

Nightwatch.js​

We implemented our test smoothly with the help of a quick start guide and automated onboarding. Nightwatch.js offers the possibility of integrating existing projects, supporting both JavaScript and TypeScript.

const selectors = require('./common/selectors');
const mock = require('./common/mock');

describe('Nightwatch.js', function () {
  it('Nightwatch.js', async function () {
    await browser
      .mockNetworkResponse('http://localhost:3000/random-quote', {
        status: 200,
        body: JSON.stringify(mock),
      })
      .navigateTo('http://localhost:3000')
      .assert.textEquals(selectors.title, 'Quotez')
      .assert.elementPresent(selectors.contentEmpty)
      .assert.textEquals(selectors.contentEmpty, '...')
      .click(selectors.trigger)
      .assert.elementPresent(selectors.content)
      .assert.textMatches(selectors.content, `${mock.quote} by ${mock.author}`);
  });
});

👎 Disliked​

• Does not support mock network requests across all supported browsers.
• We found outdated documentation. The code generated during onboarding is not in sync with the documentation. The docs mention npx nightwatch tests/ecosia.js, which with the new structure should be npx Nightwatch tests/specs/basic/ecosia.js.
• Having the tests break because you've deleted empty auto-generated folders is a frustrating experience.

👍 Liked​

• No config tweaking is necessary to run the test.
• The fluent API is super consistent; you can do everything on the go: mocks, assertions, and interactions.
• Another pleasant surprise was the debug API .debug({ timeout: 20000 }), which is neat to troubleshoot your tests - many other frameworks adopt a similar API.
• The error log is nicely highlighted and formatted. Many tools don't offer visually friendly logs.
• After successfully running the test, we're positively impressed by the good terminal text reports. Logs are well formatted and have nifty step-by-step assertion statements, all by default.

Playwright​

With an automated onboarding, offering support for JavaScript and Typescript, it also comes with options to generate CI integrations (e.g., GitHub Actions). During onboarding, Playwright installs everything for us and provides a list of commands for you to start immediately.

const { test, expect } = require('@playwright/test');
const selectors = require('./common/selectors');
const mock = require('./common/mock');

test('Playwright', async ({ page }) => {
  await page.route('http://localhost:3000/random-quote', (route) =>
    route.fulfill({
      status: 200,
      body: JSON.stringify(mock),
    }),
  );
  await page.goto('http://localhost:3000/');
  await expect(page.locator(selectors.title)).toHaveText('Quotez');
  await expect(page.locator(selectors.contentEmpty)).toBeVisible();
  await expect(page.locator(selectors.contentEmpty)).toHaveText('...');
  await page.locator(selectors.trigger).click();
  await expect(page.locator(selectors.content)).toBeVisible();
  await expect(page.locator(selectors.content)).toHaveText(`${mock.quote} by ${mock.author}`);
});

👎 Disliked​

There's nothing major to dislike about Playwright. Like other test libraries and frameworks that leverage async/await, tests might feel bloated in the number of await statements. Still, we believe this is a minor detail and subjective to the developer's preference.

👍 Liked​

• Outstanding onboarding, fast and practical, giving us the commands to run a test immediately. The example generated as boilerplate it's small but contains just the right amount of information for anyone to get started.
• Friendly test reporting, with a local server delivering an HTML report that outlines test failures and passes. For fails, it points to the line of code where you made a mistake and gives a nice call log in a human-readable format.
• The debugging mode has a red dot (pointer) to indicate the cursor position and show you where the click interactions happened; this is extremely handy; it can help uncover the most challenging bugs.
• The stepping debugger in a separate window allows developers to step through a test script line by line! The debugger is impressive, and we haven't seen anything like it.
• The config file is super intuitive; it comes with inline comments for each config property.
• The assert API feels like working with Jest; hats off to the Playwright team on an intelligent API design, not reinventing the wheel, reducing the friction between different technologies.
• Mocking requests only require a single statement.

Puppeteer​

Puppeteer does warn us that it's a general-purpose library, not a testing library; this is felt right from the start. Alone, Puppeteer is not enough; this is the first time we face this entry barrier, given all the other frameworks have an integrated test runner. We've picked Jest to bypass the setup process as quickly as possible.

const puppeteer = require('puppeteer');
const selectors = require('./common/selectors');
const mock = require('./common/mock');

it('Puppeteer (powered by Jest)', async () => {
  const browser = await puppeteer.launch({ headless: true }); // headless: false to see the browser
  const page = await browser.newPage();
  await page.setRequestInterception(true);
  page.on('request', (request) => {
    if (request.url().endsWith('/random-quote')) {
      request.respond({
        status: 200,
        contentType: 'application/json',
        body: JSON.stringify(mock),
      });
    } else {
      request.continue();
    }
  });
  await page.goto('http://localhost:3000', { waitUntil: 'networkidle0' });
  const titleEl = await page.$(selectors.title);
  const title = await titleEl.evaluate((e) => e.textContent);
  expect(title).toEqual('Quotez');
  const emptyContentEl = await page.$(selectors.contentEmpty);
  const emptyContentText = await emptyContentEl.evaluate((e) => e.textContent);
  expect(emptyContentText).toEqual('...');
  const triggerEl = await page.$(selectors.trigger);
  await triggerEl.click();
  await page.waitForNetworkIdle();
  const contentEl = await page.$(selectors.content);
  const contentText = await contentEl.evaluate((e) => e.textContent);
  expect(contentText).toEqual(`${mock.quote} by ${mock.author}`);
  await browser.close();
});

👎 Disliked​

• In this case, we need to set up everything from scratch, including additional tooling (Jest).
• Error logs are not readable. Pay attention not to make errors while you write your tests (especially missing the await keyword somewhere 🔥). Unreadable error stack traces can be demotivating for anyone trying to troubleshoot a failing test.
• Tests are too verbose, which is reflected by the number of LOC for our simple test compared with other alternatives.
• Having run our simple test a couple of times in the non-headless mode, we've ended up with lingering Chromium instances that require forceful shutdown. Lingering chromium instances are most likely related to our Jest integration and how we lack proper handling for teardown. We think this is an unnecessary extra problem, which we can easily circumvent by picking another framework.

👍 Liked​

• API is very minimalistic. With .evaluate you can do everything "just" knowing JavaScript.
• The ability to explicitly wait for the page to idle is neat; it gives you more control over what's happening in the browser compared to the auto-retry timeout approach many other frameworks adopt. Nope, this control won't save you from flaky tests.

  await page.goto('http://localhost:3000', { waitUntil: 'networkidle0' });
  

• Mocking requests is super easy. The event-driven interception API is simple to use.

TestCafe​

Instead of onboarding, TestCafe jumps from the installation to writing the first test because there's no setup required!

const { Selector, RequestMock } = require('testcafe');
const selectors = require('./common/selectors');
const mock = require('./common/mock');

const tcMock = RequestMock().onRequestTo('http://localhost:3000/random-quote').respond(JSON.stringify(mock), 202);

fixture`TestCafe`.page('http://localhost:3000').requestHooks(tcMock);

test('TestCafe', async (t) => {
  await t
    .expect(Selector(selectors.title).innerText)
    .eql('Quotez')
    .expect(Selector(selectors.contentEmpty).exists)
    .ok()
    .expect(Selector(selectors.contentEmpty).innerText)
    .eql('...')
    .click(Selector(selectors.trigger))
    .expect(Selector(selectors.content).exists)
    .ok()
    .expect(Selector(selectors.content).innerText)
    .eql(`${mock.quote} by ${mock.author}`);
});

👎 Disliked​

• There are some security concerns with the amount of OS permission-related popups we've faced when running the test for the first time. We haven't experienced this with any other framework. It seems unnecessary to have video recording enabled by default (for example).
• Inconvenient API design for RequestMock. Any other alternative does a better job here.
• Overall, TestCafe's API design does not match its competitors, but overall a good experience, excluding setting up network request mocking.
• Although our example is minimalistic, the dashboard is much slower to start than the Cypress dashboard or the Playwright debugger.

👍 Liked​

• There's no setup required and no boilerplate, which feels fantastic. Zero configuration is why we wrote our first test in 25 minutes, one of our fastest.
• Just like with Nightwatch.js, we're impressed with the text reports on the terminal.
• Error stack traces make recommendations about correct API usage.

Webdriver.io​

The only framework whose test case we couldn't fully complete is Webdriver.io. Although it has a quick start guide and familiar APIs, there are inconsistencies in the documentation that made the experience a bit bumpy. We spent about 30 minutes debugging the following error:

Proxy error: Could not proxy request /random-quote from localhost:3000 to http://localhost:3000.

See https://nodejs.org/api/errors.html#errors\_common\_system\_errors for more information (ECONNRESET).

As of today, we still don't know how to mock network requests with Webdriver.io, while we managed to do it effortlessly with all other alternatives. Again, this is just a detail, and the problem is undoubtedly on our end, but our level of effort here was way higher than other frameworks, which should tell us something.

const selectors = require('./common/selectors');
const mock = require('./common/mock');

describe('Webdriver.IO', () => {
  it('Webdriver.IO', async () => {
    // Proxy error: Could not proxy request /random-quote from localhost:3000 to http://localhost:3000
    // const iomock = await browser.mock('http://localhost:3000/random-quote')
    // iomock.respond(mock)
    // Proxy error: end
    await browser.url('http://localhost:3000/');
    await expect($(selectors.title)).toHaveText('Quotez');
    expect(await $(selectors.contentEmpty).isDisplayedInViewport()).toBe(true);
    await expect($(selectors.contentEmpty)).toHaveText('...');
    const btn = await $(selectors.trigger);
    await btn.click();
    // ...
  });
});

👎 Disliked​

• Upon running the init command, Wedriver.io changed the formatting of our package.json; this feels a bit intrusive.
• The generated boilerplate was out of place even though we provided our tests directory path during the onboarding terminal prompt; this is an evident inconsistency.
• Running the first test, we are overwhelmed by the amount of logging that appears in the terminal. A small test generated a lot of noise in the logs. You can tune logging in the file wdio.conf.js through the logLevel property, but a more balanced default logging would bring a better experience.
• Writing the test took about one hour (without request mocking).
• Intellisense is not working for the most critical API, the selector $ interface.
• Error stack traces are lengthy and hard to extract useful information.

👍 Liked​

• A surprising aspect of Webdriver.io is that it allows us to plug a custom reporter with many different options.
• The selector API is neat; using the $ character as a selector feels familiar and fast to type.
• Plugging in Mocha was straightforward without requiring additional setup besides filling in the command line prompt during onboarding.

🎯 Deep dive​

We break down this analysis into four major categories.

1. Features - a comprehensive list of features that place our frameworks vis-à-vis.
2. Adoption & Popularity - how many people out there are using it? Are developers aware of this technology?
3. DX (Developer Experience) - how easy is it to write, run and debug tests? What do users have to say about these technologies? Are they satisfied after using them for a while?
4. Maintenance - are these technologies under active development? Who is contributing to them? Are issues quickly addressed?

Features​

Cypress and Playwright stand out with an almost perfect score in our feature table. The differences in the table might look minor, but there's a lot more to it. Cypress runs on the browser, which means the test scripts you write are embedded with the target application; hence it is very likely that Cypress will never support features such as multi-window orchestration. Another limitation (fixed recently) is that Cypress can only visit same-origin domains. That's not the case with Playwright; it runs on Node.js and interacts with the browser through APIs such as Chrome Devtools Protocol, bypassing Cypress limitations. How much value can Cypress deliver while running embedded in the browser? And how much of that will be unmatched by Playwright? Only time will tell.

We were surprised to learn that TestCafe and Webdriver.io are the browser support category's champ, but that won't be a differentiator for much longer now that Microsoft has finally sunsetted Internet Explorer. Options such as Nightwatch.js and Playwright are now equally competitive in browser support.

Adoption & Popularity​

Cypress has a good reputation, which means it will be around for a good while, whether you love it or hate it. Cypress has a broad social presence and a large community. We think Puppeteer scores well due to its broader scope as a library. An interesting observation on Webdriver.io is that despite the low levels of usage reported in the state of js survey, it has quite some traffic on npm; we believe this is due to native mobile developers using Webdriver.io to write tests. Most likely, mobile developers do not overlap with the respondents' group for the state of js survey.

DX (Developer Experience)​

We're happy to see that these numbers align with our experience. We believe onboarding and documentation are pilar to creating a good DX and reducing the learning curve. Another vital aspect that the two technologies (Cypress and Playwright), with the best DX scores, can't afford to miss is debugability. Functionalities such as stepping debuggers and friendly stack traces reduce friction, making developers less frustrated.

Maintenance​

Playwright has superior numbers here. The number of monthly commits and the average time for issue resolution indicates that the Playwright team is developing faster than others. On top of that is backed by Microsoft. We can not ignore that companies such as Cypress are more prone to impact during unstable economic periods.

Another critical aspect is whether there are knowledge silos in the frameworks' core teams. A project primarily maintained by a single developer is at a higher risk of being discontinued. Life is unpredictable, and there are many reasons why that person would stop contributing to that project. Consider that Nightwatch.js and Webdriver.io run as a "one-person operation", while others have larger core teams behind the scenes.

🔮 Predictions​

This section is great because it will allow us to come back in a few years and understand how wrong we were.

• Conspiracy theory: With VSCode and the acquisition of GitHub, Microsoft has demonstrated to be investing strongly in the open source ecosystem for the past few years. We think that Microsoft could buy out Cypress.io to monopolize the JavaScript browser testing space; this could be another space for Microsoft to thrive (although, realistically, JavaScript testing frameworks feel too niche for a company like Microsoft).
• Applications are increasingly complex; we think the restrictions imposed by Cypress will pave the road for Playwright to catch up in a year or two. We foresee the usage scores to go up for Playwright.
• The Browserstack acquisition of Nightwatch.js will positively impact the project. Now backed by a larger tech organization with a powerful presence in the software testing industry, Nightwatch.js has the resources to thrive.
• The discontinuation of Internet Explorer means that TestCafe and Webdriver.io will lose the edge of broader browser compatibility; things even out in this category, leaving fewer excuses for developers not to adopt Cypress, Playwright, or even Nightwatch.js.

⚖️ Conclusion: Our pick​

The excellent DX, quick start and documentation make Playwright the best option at this time.

We hope this article becomes a good decision-making tool for you to pick the best JavaScript E2E testing framework.

If you liked this article, consider sharing (tweeting) it to your followers.

Testing dimensions​

Software testing has many dimensions, but talking specifically about frontend applications, developers are mainly concerned about:

• Functionality - does it work? Does the application react per my actions?
• Visual - does it look good? Are things aligned?
• Compatibility - does the app works seamlessly across all the different supported browsers and devices? Typically companies keep lists of support browsers and devices in publically accessible spaces.
• Performance - does it load fast? Does it perform well on lower-end devices?
• Security - are there any security holes introduced?
• Accessibility - is the app accessible? Could a visually impaired user navigate and use the app?
• Legal/Compliance - are we infringing any user rights laws (e.g., GDPR)? Do these apps make use of cookies and or other browser storage capabilities?

Kinds of tests​

The above section focuses on dimensions (or categories). But within most categories, you will find various options to implement your tests. We will try to briefly go through the most prominent ones:

• Unit tests - are typically small and focused around a tinier piece of your code. Usually, run in isolation, which means they run in controlled environments which don't greatly reflect how real-world users interact with your product.
• Integration tests - taking a step further from unit tests. Let us still focus on a particular part of the product. We stretch the scope of a unit test and introduce other components into play.
• End-to-end tests - these should test the product as a whole, no more hiding. The software that runs these tests has the job of playing the role of the user, meaning actually simulating user interactions. Due to their nature, these are typically slower and, hence, more expensive than the two previous types.
• Smoke tests - these are basic health checks for your products. A smoke test typically serves as a guiding light on whether your system is currently available. This is useful for the purposes of monitoring and alerting.

Tools​

That's a lot to take in! Let's see what tools are helping us cover most of the above.

• Functionality - typically covered through software testing automation. Jest (unit testing), Cypress, Playwright, and Puppeteer (integration/e2e testing) have risen in popularity over the past years. In addition, no-code solutions have been a hot topic recently, so you will find emergent solutions such as katalon in this space.
• Visual - a group of tests that has gained more traction recently. We have Storybook (chromatic add-on), and mpbox/pixelmatch (with a Jest wrapper available americanexpress/jest-image-snapshot). Beyond libraries, you have platforms such as saucelabs and applitools, the latter more specialized in visual testing.
• Compatibility - cross-device/browser testing could fit in the functionality bucket. Some of the previously mentioned tools will allow you to run your automation across different browsers, operative systems, and devices. If manual testing is required, BrowserStack is probably the leading tool offering a comprehensive list of device types and browsers that can be accessed on-demand through your browser (independently of your computer/OS. For compatibility (like many of the below dimensions), static code analysis might help prevent disasters. Tools such as eslint-plugin-compat allow developers to check for compatibility issues as they code.
• Performance - Google's lighthouse is undoubtedly a big player in this field, allowing you to automate performance audits for your web applications. With the proper integration, you can spot performance degradation at each step.
• Security - along with accessibility, one of the most neglected testing dimensions, has cost large corporations too much to ignore. We've seen the rise of platforms such as Snyk. This can help you scan for vulnerabilities across your codebases to prevent malicious code from going out with your software. No wonder this space has seen a record-breaking 2021 in cybersecurity startup investments.
• Accessibility - another neglected space where axe seems to be the consensual option that powers many integrations. For example, you will find plugins to use the axe-core with libraries such as Jest or Playwright.
• Legal/Compliance - with GDRP out to get you, it's crucial that you pay attention to details such as the use of cookies and user tracking. We are unaware of automation that could help you here, so if this concerns you, you'll probably have to outsource this to legal experts.

Note that in the above list, some of the tools mentioned in one testing dimension cover much more.

How much can you automate?​

For your application to have fully automated checks, you will require not only the tools above but also consider:

• Money - many of these tools are free, others quite pricey. Regardless of pricing, if you work with teams, you need to have automated pipelines that run this for you hosted somewhere (e.g., GitHub actions), and these resources alone have costs.
• Human resources - in line with money, you need people to put this automation in place and maintain them. Depending on your systems' complexity, you might require the assistance of well-paid experts.
• Time - putting these systems in place takes time.

Maybe you have good unit and functional tests that cover most of the cases of your application, but you don't have the expertise to run visual tests. Maybe you work for a big tech company with loads of cash, and you have all the mentioned above in your automation pipeline and other tools that the typical developer won't hear about until 2070. But yet, you're still releasing bugs from time to time. Finding the right balance between how much you can automate and how much human testing is required is the problem you should be focusing on. Evaluate where you and your project/company stand across the different testing dimensions and try to craft the best strategy, but while at it, better to hold and advocate for a testing mindset for your team.

When you can't automate​

You'll often have to find ways to cover the gaps your automation might leave behind. Next, we'll present a list of different methods to get your product manually tested. You can combine multiple of them with your automation to optimize how much ground your team can cover.

• Quality assurance as a mandatory step - set up an approval process for code changes where any given developer must have their changes manually tested by a peer. Sometimes this is part of the code review process, meaning that a developer is responsible for accessing the code quality and approach through the standard review process and manually testing the code changes to approve a given code change (typically a pull/merge request). This is far better than having the code author test their own changes because authors can easily have blindspots caused by their familiarity with the functionality at hand, usually missing very obvious details that an "outsider" would immediately catch.
• Have a checklist to make your developer's life easier that outlines every testing dimension your developer should care about, e.g., "Does the new code work in Safari? Does the new code respect our accessibility standards?". This list should complement your automation.
• Dogfooding - another common way large organizations test their products nowadays is by using the product. Simple right? The idea of dogfooding is to integrate your own product as a mission-critical piece of your own team/company processes. Additionally, most companies will internally run a "beta" version of those products, meaning they purposely leave their customers a few versions behind to leave room for their staff to catch bugs while using the most recent version. This is a brilliant concept that everyone should seriously consider.
• Assign a quality assurance person to your team - in an ideal world, you would have dedicated testers whose job is to create a bug barrier and assess every single code change before it reaches production.
• Outsource - get outside help to perform the testing you need. You will find plenty of offers across the web from companies or freelancers to test your products.
• Closed beta programs - ok, you don't have the funds to outsource just yet. You might want to trade off some of your customers and turn them into testers. This strategy is most commonly used to gather feedback from your users before launching a particular functionality, allowing you to work behind the scenes and iterate while the final product is not publically available. But why not also consider these users as your testing staff? You could leverage them by creating tools and communication channels that make them want to report issues to you.

We hope this article helps you get the big picture of testing frontend applications and give you a couple of alternative ideas to complement your automated checks with some manual testing processes.

If you liked this article, consider sharing (tweeting) it to your followers.