What's the difference between OpenAPI and Swagger?

OpenAPI 2.0 was 'Swagger 2.0' — same thing, renamed in 2015 when the spec moved to the OpenAPI Initiative. OpenAPI 3.0 (2017) and 3.1 (2021) are subsequent versions with substantial improvements (better security, multiple servers, callbacks). 'Swagger' now refers to the tools (Swagger UI for rendering, Swagger Codegen for client generation). Most people use the names interchangeably; most modern specs are OpenAPI 3.x.

API surface area is a useful metric. Common applications: (1) testing budget — each endpoint needs tests; (2) security review — each endpoint is an authentication/authorization risk surface; (3) documentation — each endpoint needs docs and examples; (4) deprecation planning — knowing total count helps estimate migration effort.

What's the difference between a path and an operation?

A path is a URL pattern (e.g. `/users/{id}`); an operation is a path + method combo (e.g. `GET /users/{id}` and `DELETE /users/{id}` are two operations on the same path). A typical REST API has 2-5 operations per path (GET to read, POST to create, PUT/PATCH to update, DELETE to remove). Total operations is usually a better metric than total paths.

What about parameters and request bodies?

This tool counts paths and operations, not the depth (parameter count, schema complexity). For deeper analysis use Stoplight's Spectral or run openapi-stats which counts schema items, parameter usage, response codes per operation, etc.

Can it handle very large specs?

Browser memory is a soft limit. Specs under ~5MB parse instantly; larger specs (10MB+) may take several seconds and very large ones (50MB+) might fail. For massive APIs use a CLI tool like swagger-cli or oasdiff which can handle multi-hundred-MB specs.

What are operation IDs?

Optional unique identifier for each operation (e.g. 'getUserById', 'listProducts'). When present, code generators use them to name client SDK methods. Best practice: every operation should have an operationId. The counter flags operations missing them.

Developer Utilities · Free tool

OpenAPI Endpoint Counter

Paste an OpenAPI 3 spec — see paths by method, operation IDs, and count endpoints at a glance.

Updated June 2026

OpenAPI 3 JSON

get

post

put

patch

delete

Endpoints — 6

GET/orderslistOrders
GET/userslistUsers
POST/userscreateUser
GET/users/{id}getUser
PATCH/users/{id}updateUser
DELETE/users/{id}deleteUser

Found this useful?Email Buy Me a Coffee

What it does

Paste an OpenAPI spec (YAML or JSON, version 2.0 / 3.0 / 3.1) and the tool gives you a fast inventory: total path count, method counts (GET / POST / PUT / PATCH / DELETE / OPTIONS / HEAD breakdown), full list of operations with their operationIds, and tag-grouped summary. Useful for quickly understanding the size and shape of an API before diving deeper, comparing two versions of a spec, or auditing for inconsistent method usage.

OpenAPI (formerly Swagger) is the de facto standard for REST API description. The spec was donated to the Linux Foundation by SmartBear in 2015 and renamed OpenAPI Initiative; the previous name “Swagger” now refers specifically to the surrounding tooling (Swagger UI, Swagger Codegen). Most modern API frameworks (FastAPI, NestJS, Spring, Express with swagger-jsdoc) generate OpenAPI specs automatically; most modern API tools (Postman, Insomnia, Stoplight, Bruno) consume them.

Common uses: API audit (count endpoints to gauge surface area for testing, security review, or deprecation planning); migration planning (when migrating to a new API, count what you need to support); spec validation (the parser surfaces structural errors and missing fields); quick spec comparison (paste v1, count; paste v2, count; diff). For richer diffing use openapi-diff (npm) or oasdiff (CLI tool).

Embed this tool on your siteShow snippet

Paste this snippet into any page. Loads on-demand (lazy), no tracking scripts, and sized to most dashboards. Replace the height to fit your layout.

<iframe src="https://freetoolarena.com/embed/openapi-endpoint-counter" width="100%" height="720" frameborder="0" loading="lazy" title="OpenAPI Endpoint Counter" style="border:1px solid #e2e8f0;border-radius:12px;max-width:720px;"></iframe>

Embed docs →

How to use it

Paste your OpenAPI spec — YAML or JSON. The parser auto-detects format.
Read the summary: total paths, total operations (multiple operations per path), method breakdown, and per-tag operation counts.
Scan the operation list — each operation shows path + method + operationId + tags. Sortable by any column.
If your spec has multiple servers or version branches, pick which one to count (or count all).
Export as CSV for spreadsheet analysis or further diffing.

When to use this tool

First-look inventory of any new API spec — quickly understand scope.
Migration planning when consolidating multiple APIs or moving to a new one.
Audit / compliance work — count endpoints subject to security review.
Comparing API spec versions before a release.

When not to use it

Deep diff analysis — use openapi-diff or oasdiff for change-by-change comparison between two specs.
Schema validation — for full validation use Spectral (Stoplight's linter) which checks both structure and best practices.
Code generation — use openapi-generator (Java tool) or openapi-typescript (TS-specific) which generate full client SDKs.
GraphQL or gRPC APIs — those have different IDLs (GraphQL Schema Definition Language, Protocol Buffers). OpenAPI is REST-specific.

Common use cases

Verifying a number or output before passing it on
Quick use during a typical workday
Pre-decision sanity-check on inputs and outputs
Educational use — demonstrating the underlying concept

Frequently asked questions

What's the difference between OpenAPI and Swagger?: OpenAPI 2.0 was 'Swagger 2.0' — same thing, renamed in 2015 when the spec moved to the OpenAPI Initiative. OpenAPI 3.0 (2017) and 3.1 (2021) are subsequent versions with substantial improvements (better security, multiple servers, callbacks). 'Swagger' now refers to the tools (Swagger UI for rendering, Swagger Codegen for client generation). Most people use the names interchangeably; most modern specs are OpenAPI 3.x.
Why count endpoints?: API surface area is a useful metric. Common applications: (1) testing budget — each endpoint needs tests; (2) security review — each endpoint is an authentication/authorization risk surface; (3) documentation — each endpoint needs docs and examples; (4) deprecation planning — knowing total count helps estimate migration effort.
What's the difference between a path and an operation?: A path is a URL pattern (e.g. `/users/{id}`); an operation is a path + method combo (e.g. `GET /users/{id}` and `DELETE /users/{id}` are two operations on the same path). A typical REST API has 2-5 operations per path (GET to read, POST to create, PUT/PATCH to update, DELETE to remove). Total operations is usually a better metric than total paths.
What about parameters and request bodies?: This tool counts paths and operations, not the depth (parameter count, schema complexity). For deeper analysis use Stoplight's Spectral or run openapi-stats which counts schema items, parameter usage, response codes per operation, etc.
Can it handle very large specs?: Browser memory is a soft limit. Specs under ~5MB parse instantly; larger specs (10MB+) may take several seconds and very large ones (50MB+) might fail. For massive APIs use a CLI tool like swagger-cli or oasdiff which can handle multi-hundred-MB specs.
What are operation IDs?: Optional unique identifier for each operation (e.g. 'getUserById', 'listProducts'). When present, code generators use them to name client SDK methods. Best practice: every operation should have an operationId. The counter flags operations missing them.

Learn more

Explore more developer utilities tools

100% in-browserNo downloadsNo sign-upMalware-freeHow we keep this safe →