HAR to OpenAPI Generator
Upload a captured HAR file and get a starting OpenAPI 3.0 spec — paths, parameters, and request/response schemas inferred from real traffic.
An OpenAPI spec is easiest to write when the API already exists and you can watch it in action. This tool takes a HAR file — the standard network-capture format every browser's DevTools can export — and turns real requests and responses into a starting OpenAPI 3.0 document, instead of you transcribing every endpoint by hand.
- ✓Upload a .har file exported from any browser's Network tab
- ✓Repeated requests to /users/123, /users/456… collapse into one templated path
- ✓Query parameters and JSON request/response bodies inferred automatically
- ✓Every captured status code becomes its own documented response
- ✓100% private — parsing happens entirely in your browser
Capturing a HAR File
- Open your browser's DevTools (F12) and switch to the Network tab.
- Use the app normally so the requests you want documented actually fire — browse the flows that matter.
- Right-click anywhere in the request list and choose "Save all as HAR with content" (Chrome/Edge) or "Save All As HAR" (Firefox) — the "with content" option matters, since it's what includes response bodies.
- Drop the downloaded
.harfile into this tool.
How Path Templating Works
A real capture session usually hits the same endpoint with different ids — GET /users/8f2a, GET /users/91cd — which would otherwise produce a separate, useless OpenAPI operation per request. This tool detects path segments that look like variable identifiers (purely numeric, a UUID, a 24-character Mongo ObjectId, or a long mixed alphanumeric token) and replaces them with a named parameter, so every request to the same logical endpoint collapses into one operation:
GET /users/8f2a91 ┐
GET /users/91cd44 ├─► GET /users/{param1}
GET /users/2b7e19 ┘What Gets Generated, and What Doesn't
Paths, HTTP methods, path/query parameters, and JSON request/response body schemas (typed from the captured example values) are all generated automatically. What isn't: authentication schemes, detailed field descriptions, examples beyond the inferred type, and non-JSON bodies (form-encoded, multipart, XML) are skipped since there's no reliable way to infer a JSON Schema from them. Treat the output as a working first draft — review it, then refine field descriptions and add security schemes by hand, ideally in JSON Formatter or your usual OpenAPI editor.
Common Uses
- ▸Documenting an undocumented API — Reverse-engineer a starting spec for a third-party or internal API that has no published documentation, by capturing how the existing frontend actually uses it.
- ▸Onboarding onto an unfamiliar service — Get a structured overview of an internal microservice's endpoints without reading its source code or asking another team.
- ▸Kickstarting API client generation — Produce a first-draft OpenAPI spec you can refine, then feed into a client generator instead of hand-writing request functions.
- ▸Auditing what a frontend actually calls — Capture a full user session and see every endpoint, method, and parameter combination a page genuinely exercises — useful before a backend refactor.