Does this detect path parameters like /users/{'{id}'}?

No. Each literal path is kept as-is, so /users/123 and /users/456 appear as two separate paths rather than being merged.

Are request/response bodies included as schemas?

No. This generates the paths and responses skeleton only, no requestBody or response schemas are inferred.

Can I edit the output further?

Yes; it's meant as a starting skeleton. Add schemas, parameters, and descriptions by hand, or feed it into an OpenAPI editor.

HAR to OpenAPI

Turns a captured .har file into a minimal OpenAPI 3.0 YAML skeleton, one paths entry per literal path, grouped by method, with the status codes actually observed. A starting point, not a finished spec.

Private by architecture: All processing is 100% client-side memory. Your data never leaves this browser tab.

HAR input

0 charsJSON

OpenAPI 3.0 YAML

0 charsYAML

About This Tool

Reuses the same HAR parsing as HAR File Viewer, then groups requests by their literal URL path (query string stripped, no {id}-style parameter detection; this keeps the generator simple and fully deterministic) and HTTP method, listing every status code that was actually observed for each path+method pair.

This is a best-effort skeleton, not a complete OpenAPI spec. It has no request/response body schemas, no parameter definitions, and no path-parameter normalization (/users/123 and /users/456 become two separate paths, not one /users/{id}). Treat the output as scaffolding to hand-edit, not a finished contract.

Key Features

Grouped by path + method: one operation per unique combination seen in the capture.
All observed status codes: if a path returned both 200 and 500 across the capture, both show up.
Query strings stripped - /users?page=1 and /users?page=2 collapse into one /users path.
Deterministic output: paths, methods, and status codes are sorted, so the same HAR always produces the same YAML.
Hand-written YAML emitter: no external library; output is plain, minimal OpenAPI 3.0 syntax.

Example

A HAR with a GET /users (200) and a POST /users (201, then 500 on retry) produces:

openapi: 3.0.0
info:
  title: Generated API (from HAR)
  version: "1.0.0"
paths:
  /users:
    get:
      summary: GET /users
      responses:
        "200":
          description: OK
    post:
      summary: POST /users
      responses:
        "201":
          description: Created
        "500":
          description: Internal Server Error

FAQ

Does this detect path parameters like /users/{id}?: No. Each literal path is kept as-is, so /users/123 and /users/456 appear as two separate paths rather than being merged.
Are request/response bodies included as schemas?: No. This generates the paths and responses skeleton only, no requestBody or response schemas are inferred.
Can I edit the output further?: Yes; it's meant as a starting skeleton. Add schemas, parameters, and descriptions by hand, or feed it into an OpenAPI editor.