HMPL Render & Mock API Studio – Free Offline REST & GraphQL Mock Server with

Front end ready but the real API is not built yet? Define mock REST and GraphQL responses and render templates against them, so you can keep building the interface while the backend catches up. It intercepts fetch requests in the browser and returns the responses you define, complete with status codes, latency and even flaky-endpoint simulation, so your app behaves as if a real server were answering. That lets you prototype data-driven views, demo a feature, or reproduce an awkward error state without touching a live endpoint. You can import an OpenAPI or Swagger spec to generate routes automatically, and export to Postman, cURL or fetch when you are ready to wire up the real thing. Everything runs on your device with nothing uploaded, so it stays available offline once the page has loaded.

Build, Render, and Mock APIs Without a Server

Easily test and compile HMPL templates entirely offline with our advanced HMPL render utility. Features a built-in mock API server and live preview.

 
HMPL render utility

Mock API Studio

Mock REST & GraphQL endpoints, stateful responses & OpenAPI import — fully offline

v6.0 🔒 100% Offline ⏹️ Server off

Routes

Route editor

Tokens: {{id}} path params, {{$uuid}}, {{$timestamp}}, {{$randomInt}}, {{$incrementId}}, and {{baseUrl}} environment vars. Sequential = one body per line-separated JSON block (split on a line with only ---).

Need to generate large fake datasets, diff two payloads, query JSON, or write code with AI? Use Dummy Data Generator, Text Diff, JSON Studio, or AI Code Studio.

GraphQL mock endpoint

A single POST endpoint. Requests are matched by the operation/field name in the query, and the matching response below is returned wrapped in { "data": ... }.

Environment variables

Use these anywhere in a path, header, or response as {{name}}. Handy for a shared base URL or token across many routes.

Request log

TimeMethodPathStatusmsSource

Turn the server on and send a request (or press Send Test Request) to see traffic here.

Bind a response to a template

Supports {{field}}, nested {{a.b}}, and {{#each list}}...{{/each}}. Output is sanitised before preview.

Preview

Import OpenAPI / Swagger

Paste an OpenAPI 3.0 or Swagger 2.0 JSON spec. Each path + method becomes a mock route with an example response.

Export

Last Updated: August 2026

🟢 Build The Front End Before The Back End Exists

Most interface work stalls for the same reason: the screen needs data, and the endpoint that serves it is still being written. The usual workaround is a hardcoded array pasted into the component, which works right up until the real API arrives with different field names and a loading state nobody planned for.

A mock API removes that stall. You describe the endpoints your screen expects, your code calls them normally with fetch, and the answers come back from inside the page. No server to install, no configuration file, nothing uploaded.

TabWhat it handles
Mock ServerRoute table with method, path parameters, status code, headers, delay and per-scenario bodies
TemplateLive HMPL rendering against those routes, cleaned before it is shown
InspectorEvery intercepted request with timing, matched route, parameters and full response
ExportOpenAPI 3.0, Postman collection, fetch, axios and cURL snippets, plus a share link

🟡 Making Your First Route

  1. Press Load Sample to see three working routes, or New Route to start clean.
  2. Set the method and path. Use a colon for anything variable: /api/users/:id.
  3. Choose a status code and a delay. Three hundred milliseconds is closer to reality than zero.
  4. Write the response body. JSON5 is accepted, so unquoted keys and trailing commas will not stop you.
  5. Press Save Route, then Send Test Request to confirm it answers.

Path parameters in the body

A parameter you capture in the path can be used in the response. One route then answers for every record:

Path:  /api/users/:id
Body:  { id: {{id}}, name: "User {{id}}", role: "Member" }
 
GET /api/users/42  ->  { "id": 42, "name": "User 42", "role": "Member" }
GET /api/users/7   ->  { "id": 7,  "name": "User 7",  "role": "Member" }

🔴 The Feature Worth Learning First

The scenario selector at the top is the part that changes how you work.

Every route carries three bodies rather than one: a success response, an empty response, and an error response with its own status code. The selector switches all of them at once.

Load the sample, leave the template rendering, and change the selector from Success to Empty. The list has no rows now – does your screen show a helpful message, or a blank rectangle that looks broken? Change it to Error and the same route answers 503. Does anything tell the user what happened?

Interfaces are almost always built against the happy path and then meet reality in production. Three seconds of clicking a selector tests the states that actually generate support tickets: nothing to show, something went wrong, and it is taking a while.

🟢 Two Jobs This Handles Well

Agreeing the shape before anyone writes code

Sketch the endpoints you think the screen needs, fill in sample bodies, then export an OpenAPI specification from the Export tab. That file is a concrete thing to review with whoever is building the back end, and it is far easier to change a mock than a finished controller.

Reproducing a slow or failing endpoint

A bug that only appears when one call takes two seconds is painful to chase against a fast local server. Set the delay to 2000 on that route, reproduce it reliably, and watch the timing in the Inspector.

🟡 Exporting What You Designed

The Export tab turns your routes into five things, none of which need a server:

  • 🔵 OpenAPI 3.0 – a specification file describing paths, parameters and example responses.
  • 🟠 Postman collection – importable straight into Postman for manual testing.
  • 🟣 fetch and axios snippets – client code for each route, ready to paste.
  • 🔵 cURL commands – useful for a README or a quick terminal check.
  • 🟠 Share link – your whole setup compressed into the address itself, with nothing stored anywhere.

🔴 Common Mistakes and Real Limits

  • 🔵 Only listed paths are intercepted. Anything else your browser requests passes through untouched. If a route seems ignored, the path or the method usually does not match.
  • 🟠 Requests use fetch, not XMLHttpRequest. Older code built on XHR will not be caught. Modern frameworks and the template engine here all use fetch.
  • 🟣 Zero delay teaches bad habits. An instant response hides every loading state. Leave a realistic delay on so spinners and skeletons actually get exercised.
  • 🔵 A mock is a guess until the contract is agreed. If the real endpoint returns user_name and your mock says name, everything works here and breaks on connection. Export the specification and have it checked.
  • 🟠 The share link holds everything you typed. Route bodies travel inside the address, so do not paste real credentials or customer data into a link you send to someone.
  • 🟣 Rendered output is cleaned before display. Scripts inside a mock response are stripped, which is intentional. This page previews markup, it does not execute application code.

🟢 Where This Sits Next To Other Tools

This page designs and serves endpoints. Reshaping the JSON itself – querying it, converting it, validating it – belongs to the JSON Studio Pro. If you need believable filler records to put inside your responses, generate them in the dummy data generator first. The background on why mocking works and where it goes wrong is in how API mocking works.

Frequently Asked Questions

Do I need to install or run a server?

No. Requests are answered inside the page itself, so there is nothing to install, no port to start and no configuration file to maintain.

Will this interfere with other requests?

No. Only paths matching a route you defined are answered locally. Everything else passes through untouched, and the checkbox at the top pauses interception completely.

How do path parameters work?

Write a colon before the name, as in /api/users/:id. The matched value is captured and can be placed in the response body by writing the name in double braces.

What does the scenario selector do?

Each route stores a success, empty and error response. The selector switches every route at once, so you can check how your interface handles no data and failures without editing anything.

Does it capture XMLHttpRequest calls?

No, it intercepts fetch only. Modern frameworks and the template engine on this page all use fetch, but older XHR-based code will not be caught.

Can I use JSON5 in the response body?

Yes. Unquoted keys, single quotes and trailing commas are all accepted, which saves fighting with syntax while you sketch a response.

What can I export?

An OpenAPI 3.0 specification, a Postman collection, and fetch, axios or cURL snippets for every route. There is also a share link that carries the whole setup.

Is the share link stored on a server?

No. Your routes and template are compressed into the address itself, so nothing is saved anywhere. Avoid putting real credentials in a link you send to other people.

Why should I set a delay?

An instant response hides every loading state you wrote. A few hundred milliseconds makes spinners and skeletons visible, which is the only way to know they work.

Choose a language

Top Tools Ranking

Network Total Views
15,489
Tracking Since
Jul 9, 2026

Click any tool to open in a new window