You have an OpenAPI file and you want docs out of it. You don’t want to stand up a service, sign into a portal, or add a build step that pulls in half of npm. You want one command that reads the spec and hands you a Markdown file or a single HTML page you can host anywhere.
That’s what this list is for. Every tool here is small: a single binary, an npx one-liner, or a package you install once and forget. They start fast, need little or no config, and do the documentation job without dragging a full platform behind them. Some emit Markdown you drop into an existing docs site. Some emit a standalone HTML file. All of them run in CI and in a terminal, which is the point.
If you want the broader field of documentation platforms, the top REST API documentation tools roundup covers the GUI-heavy end. This piece is the terminal-first, low-footprint cut. For the official reference on what a documentation generator reads, the OpenAPI Specification is the source of truth every tool below parses.
What makes a CLI tool “lightweight” for API documentation
Lightweight isn’t about being underpowered. It’s about footprint and friction. Four things decide it.
Install size and dependencies. One binary or one npm package beats a framework. If generating a docs page means installing a language runtime plus a bundler plus a plugin system, that’s not lightweight, whatever the output looks like.
Startup and config. The best of these read your spec and produce output with zero config. You point the command at openapi.yaml and get a file back. Anything that needs a config file before it will run at all loses points here.
Single-purpose output. Each tool below does one thing: spec in, docs out. Markdown or HTML, nothing else bolted on. That’s what keeps them fast and predictable in a pipeline.
Runs anywhere. No GUI, no login for the open tools, no server to keep alive. It works on your laptop and it works the same way in a CI job. For a wider set of no-cost options, the free API documentation tools list has the platforms; this is the CLI slice of that.
Now the tools, smallest first.
Widdershins
Widdershins is about as small as this gets. It’s a single npm package that converts an OpenAPI 3, Swagger 2, or AsyncAPI file into Markdown. That’s the whole job. It doesn’t render a site or run a server; it hands you a .md file and gets out of the way.
npm install -g widdershins
widdershins openapi.yaml -o api-docs.md
The Markdown it produces is Slate-compatible, which matters if you plan to feed it into a static site later. Useful flags: --omitHeader drops the YAML front-matter, and --language_tabs controls which code-sample languages show up.
Best at: getting spec content into Markdown you can commit, diff, and drop into any docs system. Honest limits: Markdown is all you get. There’s no styling, no interactive “try it” panel, and no hosted output. Widdershins is a converter, not a renderer, so you pair it with something that turns Markdown into a site.
OpenAPI Generator (docs generators)
OpenAPI Generator is best known for client SDKs, but it ships documentation generators too, and they’re handy when a spec is all you have. The markdown generator writes a folder of Markdown; the html2 generator writes a single self-contained HTML page. You can drive it through the npm wrapper without installing Java yourself.
npm install -g @openapitools/openapi-generator-cli
openapi-generator-cli generate -g markdown -i openapi.yaml -o docs/
openapi-generator-cli generate -g html2 -i openapi.yaml -o docs-html/
The npm wrapper still downloads a JDK-backed jar under the hood, so it’s heavier than Widdershins on first run. After that it’s a one-command generate.
Best at: reusing a tool you may already run for SDKs to also emit docs, with a choice between Markdown and standalone HTML. Honest limits: the output is plain and template-driven, and the first invocation pulls a jar, so it’s not truly single-binary. If you only need docs and nothing else, lighter options exist.
Redocly CLI (build-docs)
If you want a good-looking, standalone HTML page from a single command, Redocly CLI is the shortest path. The build-docs command bundles your spec into one self-contained HTML file built on Redoc. No server, no separate hosting build; you get a file you can open, email, or drop on any static host.
npx @redocly/cli build-docs openapi.yaml
By default it writes redoc-static.html. Change the name with --output:
npx @redocly/cli build-docs openapi.yaml --output api.html
Because it runs through npx, you don’t even have to install it globally to try it. Best at: a polished single-page reference from one command, with a clean default theme and no hosting story to manage. Honest limits: the output is one HTML file, so it’s a reference page rather than a multi-page docs portal, and the richer theming and previews sit in Redocly’s paid tiers. If you’re weighing it against similar renderers, the Redocly alternatives and Scalar alternatives comparisons lay out the trade-offs.
Slate
Slate is the odd one out here: it’s not a spec-to-docs converter, it’s a static-site generator for handwritten API docs. You write Markdown, and Slate builds the classic three-column docs layout (navigation, content, and code samples side by side) into a self-contained static site. It’s powered by Middleman, so it needs Ruby.
# after cloning the slate repo and installing dependencies
bundle exec middleman build
That writes a complete static site to a build/ folder you can host anywhere. This is where Widdershins pays off: generate Markdown from your spec, then let Slate render it, and you get spec-driven content in Slate’s layout.
Best at: hand-curated, narrative API docs where you want editorial control over structure and prose. Honest limits: it’s the heaviest option on this list because it needs a Ruby toolchain, and it doesn’t read OpenAPI on its own; you feed it Markdown. If your docs are generated straight from a spec and rarely hand-edited, a converter alone is lighter.
Apidog CLI (export + doc)
The open tools above each cover one slice: convert, render, or host. If your API already lives in a project instead of a lone YAML file, stitching them together is the friction. That’s where the apidog-cli binary fits. It’s the command-line companion to Apidog, and one export turns a project into Markdown or HTML without a build pipeline.
Install it from npm and authenticate with a token:
npm install -g apidog-cli
apidog login --with-token <YOUR_TOKEN>
Then export the project’s documentation to Markdown or HTML in one command:
apidog export --project <projectId> --format markdown --output ./api-docs.md
apidog export --project <projectId> --format html --output ./api-docs.html
The CLI also manages docs resources directly. apidog doc handles the project’s Markdown documents, and apidog docs-site manages published documentation sites, so you can list, create, and update docs from a script or CI job:
apidog doc list --project <projectId>
apidog docs-site list --project <projectId>
Output is structured JSON, which makes it easy to pipe into other steps or hand to an agent. For the full command surface, the Apidog CLI complete guide walks through auth, projects, and each command group.
Here’s the honest framing. Apidog isn’t open source, and it isn’t a single-purpose binary; it’s a freemium platform, and the CLI talks to a hosted project. It also doesn’t lint your OpenAPI or enforce a style guide; Redocly and Spectral do that. What the CLI gives you is one integrated route from a maintained API project to shareable Markdown or HTML, instead of chaining a converter, a renderer, and a host by hand. If you want the markdown-export path specifically, the API doc generator with Markdown export piece goes deeper on that workflow.
How to choose
Match the tool to the shape of your input and the output you need.
| Tool | Best for | Install | Open source? | Output |
|---|---|---|---|---|
| Widdershins | Spec to Markdown, fast | npm i -g widdershins |
Yes (MIT) | Markdown |
| OpenAPI Generator | Docs alongside SDKs | npm i -g @openapitools/openapi-generator-cli |
Yes (Apache 2.0) | Markdown or HTML |
| Redocly CLI | One polished HTML page | npx @redocly/cli |
Yes (MIT, open core) | Standalone HTML |
| Slate | Hand-curated docs site | Ruby + Bundler | Yes (Apache 2.0) | Static site |
| Apidog CLI | Export from a live project | npm i -g apidog-cli |
No (free tier) | Markdown or HTML |
The short version: if you have a bare spec and want Markdown to commit, use Widdershins. If you want one shareable HTML page, redocly build-docs is the fastest. If you’re writing docs by hand and want a proper layout, Slate. And if your API already lives in a project and you want export plus doc management in one CLI, Apidog. For a no-cost overview across the board, the free API documentation tools roundup pulls it together.
Wrapping up
Lightweight documentation tooling comes down to one rule: pick the smallest thing that produces the output you need. Widdershins and redocly build-docs cover most spec-to-docs cases in a single command. OpenAPI Generator is worth it when you’re already generating SDKs. Slate earns its heavier footprint only when you’re hand-writing docs. And when your API lives in a real project rather than a stray file, the apidog-cli export gives you Markdown or HTML without a pipeline.
If that last case is you, Download Apidog and try apidog export against a project; it drops cleanly into a CI job so your docs rebuild every time the API changes.



