OpenAPI Parameter Table Builder

How to use this developer tool

1. Paste a JSON-formatted API document or load the included sample.
2. Check that the document shape matches the label above the editor.
3. Select “Build Parameter Table” or press Ctrl/Cmd + Enter.
4. Review the summary and download the copy-ready result.

What this developer tool does

The builder converts reusable and inline parameter definitions into one tab-separated row per operation parameter.

Request bodies are not parameters and therefore do not appear in this table.

Example

The Sample button loads a small specification chosen for this operation. Running it produces the same structured fields shown in the output panel.

{
  "openapi": "3.0.3",
  "info": {
    "title": "Search",
    "version": "1"
  },
  "paths": {
    "/search": {
      "parameters": [
        {
          "name": "locale",
          "in": "header",
          "schema": {
            "type": "string"
          }
        }
      ],
      "get": {
        "operationId": "search",
        "parameters": [
          {
            "name": "q",
            "in": "query",
            "required": true,
            "schema": {
              "type": "string"
            }
          },
          {
            "name": "limit",
            "in": "query",
            "schema": {
              "type": "integer",
              "default": 20
            }
    
…

Use cases

• Review an API contract during a pull request.
• Prepare documentation or deterministic test fixtures.
• Find migration work before changing generators or clients.
• Export a focused report without sharing the source document.

Tips for reliable output

• Bundle remote references before running the page.
• Keep operation IDs stable across published versions.
• Prefer explicit examples for domain-specific values.
• Validate the complete document after applying generated output.
• Commit the original specification before a conversion.

Processing details

Local parameter references are resolved before fields are read. Array types and basic schema formats are preserved in their own columns.

Serialization styles are not expanded into example query strings. External references and Swagger 2 body parameters are outside scope.