Home › API Mocking › WireMock

WireMock Review 2026: HTTP Mocking That Behaves Like a Real Server

The JVM-based stub server that turns flaky third-party APIs into deterministic test fixtures.

Backend and platform engineers who need programmatic, stateful HTTP mocking inside JUnit, Testcontainers, or a shared standalone server their whole team can hit.
8.6
Editor score · 10
Runtime
JVM (Java 11+ for 3.x); standalone JAR, Docker, or embedded library
License
Apache 2.0 (open source); commercial hosted Cloud tier
Protocols
HTTP/HTTPS, HTTP/2, WebSocket, gRPC (extension); no native AMQP or raw TCP
Integration
JUnit 5 extension, Testcontainers module, Spring Boot, Gradle/Maven plugins
Response features
Handlebars templating, dynamic delays, fault injection, scenarios, proxy passthrough
Config format
JSON mapping files on disk, Java/Kotlin DSL, or REST admin API

Overview

WireMock's setup story is its strongest card. Download the standalone JAR, run `java -jar wiremock-standalone-3.x.jar`, and you have a real HTTP server on port 8080 that any client can hit — no language runtime drama, no framework coupling. In a polyglot shop this matters: the same stub file serves your Go service, your Python scripts, and the React dev server. For CI, the `wiremock/wiremock` Docker image drops cleanly into a compose file. One warning: pin the version explicitly. The 2.x to 3.x jump moved packages and swapped Jetty internals, and stale tutorials will have you chasing classpath ghosts for an afternoon.

Where WireMock earns its keep is record-and-playback against a flaky third party. Run it in proxy-recording mode against the real vendor endpoint once, capture traffic into mapping files, commit those, and your integration suite now runs offline at millisecond latency. I've used this to tame a payment sandbox that rate-limited us into oblivion. The catch is fidelity: recorded stubs freeze one response per request shape. If upstream returns pagination cursors or rotates IDs, you hand-edit mappings or reach for response templating with the Handlebars helpers — and that's where the effort curve steepens noticeably.

Stubbing a happy path is trivial. Modeling state is where the tool separates casual users from committed ones. Scenarios give you a finite state machine: a request in state `Started` advances to `ItemAdded`, and your cart stub answers differently depending on where the machine sits. That's genuinely good, and it catches ordering bugs that naive mocks hide. The con is that scenario JSON gets unwieldy fast, the open-source edition has no visual editor, and debugging a mismatched state means reading the request journal like a detective. Fault injection — `MALFORMED_RESPONSE_CHUNK`, fixed delays, connection resets — also lives here and is excellent for retry logic.

The honest limitation: WireMock is a server, not a contract. It will cheerfully serve a stub that no longer resembles production, and nothing fails until a human notices. Pact or schema-diff tooling solves that; WireMock doesn't, and pretending otherwise yields green suites over broken integrations. Compare it to MSW, which intercepts inside the process and needs zero ports, and the tradeoff is clear. WireMock wins when you need a language-agnostic, out-of-process target — service-to-service tests, mobile clients, or mocking on behalf of a partner team. For a single Node app, MSW is lighter and I'd reach for it first.

Pricing is refreshingly boring. The OSS standalone is free under Apache 2.0 and covers roughly 90% of what teams actually need. WireMock Cloud adds hosted stubs, a UI, and collaboration for orgs that can't or won't run their own infra — useful, but not something a solo backend engineer needs to think about. My verdict: install the standalone, commit your `mappings/` directory, run it in Docker for CI, and treat it as test infrastructure rather than a permanent runtime dependency. If you need contract guarantees, pair it with a schema check. It's the best general-purpose HTTP stub server I've used, and it stays out of your way.

How we scored it

Request matching depth 10/10
Stateful behavior 9/10
Ease of setup 7/10
Record & playback 8/10
Docs & ecosystem 9/10

Pricing

Open Source (JVM)
Free
Full stub server, JUnit 5 extension, record/playback, and the WireMock Docker image under Apache 2.0. Self-hosted, no seat limits, no phone-home.
WireMock Cloud Team
From ~$250/mo
Hosted mock APIs with a visual editor, shareable public links, OpenAPI import, and CI-triggered redeploys. Priced per workspace, so treat the number as a starting point and confirm on their pricing page.
WireMock Cloud Enterprise
Custom
SSO/SAML, private mock hosting inside your VPC, audit logs, and support SLAs. Worth it only when mock APIs become shared infrastructure other teams depend on.

In practice

json
{
  "request": {
    "method": "GET",
    "urlPath": "/api/orders/42"
  },
  "response": {
    "status": 200,
    "headers": { "Content-Type": "application/json" },
    "jsonBody": { "id": 42, "status": "shipped" },
    "fixedDelayMilliseconds": 250
  }
}

A single file dropped into mappings/ becomes a live endpoint on restart, which is why committing stubs beats hand-rolled test servers.

Quick verdict

Best-in-class for out-of-process HTTP stubbing across languages: start the standalone JAR, commit JSON mappings, and every client in your repo gets the same fake backend.

Use Scenarios and fault injection for stateful and failure-path testing; skip it as your contract source of truth and pair with schema checks instead.

Pinned version, Docker in CI, record mode for gnarly third parties. That combination has never let me down.

Pricing breakdown

Open source (Apache 2.0): free forever, includes the standalone server, the JUnit/Java DSL, record-and-playback, scenarios, and fault injection. This is what most teams should run.

WireMock Cloud free tier: a small hosted stub quota with the web UI, good for demos and sharing a mock with a frontend team that can't run local infra.

WireMock Cloud paid tiers: billed per seat and by stub/request volume; buy it when hosted collaboration and RBAC matter more than the modest monthly cost. Self-hosting on a shared dev box is the cheaper equivalent.

Verdict

WireMock is still the reference implementation of 'mock it at the network layer and stop arguing about it.' Request matching is deep, fault injection is genuinely useful, and the standalone mode means your frontend, mobile, and QA teams can all point at the same stubs. The tradeoffs are real — you are writing JSON or Java DSL, not clicking around a pretty UI — but once the mappings live in git next to the code they test, everything else feels like a downgrade.

DevKit Central is editor-independent. Some links are affiliate links; we may earn a recurring commission if you subscribe. This never affects our verdicts.

How the field scores

WireMock
8.6
Mockoon
8.6
Postman
8.0
Prism
8.4
Apidog
8.4
MockServer
8.4
Bruno
8.2
Hoppscotch
8.2
Insomnia
8.2
Swagger UI
7.6
JSONPlaceholder
7.6
HTTPie
8.4
SoapUI
7.3
Does WireMock require Java?
The OSS distribution runs on the JVM (Java 11+ for WireMock 3.x), so yes — even the standalone JAR needs a JRE. In practice that barely matters because the Docker image bundles it, and Testcontainers pulls it for you. If a JVM in your test pipeline is a hard no, look at Node-based alternatives instead.
Can I use it for frontend development without a backend?
That is the standalone mode's whole reason to exist. Run the server, point your dev proxy or axios base URL at it, and edit mapping JSON files without restarting. WireMock Cloud extends this with shareable URLs so a designer or PM can hit the same stubs from a browser.
How is this different from contract testing with Pact?
Pact verifies that a consumer's expectations and a provider's reality agree, using a broker and a verification step in the provider's CI. WireMock just serves responses you defined — it does not verify anything about the real service. Many teams use both: WireMock for day-to-day isolation, Pact for the cross-team guarantee. Using WireMock alone and calling it contract testing is a common and expensive misunderstanding.
Is record-and-playback safe for services with auth?
Proxy mode will happily capture Authorization headers into plain-text mapping files, which then get committed. Scrub them with response templating and transformers before the recordings hit git, and never record against production with real customer tokens.