What the AsyncAPI Validator and Viewer does
This page checks the structure of an AsyncAPI 3.0 or 2.x document - required fields, $ref targets and the cross-references between servers, channels, operations and messages - and turns it into readable documentation with an example payload for every message. It runs in your browser and reads YAML or JSON.
Be clear about what it is: a structural validator written for A2Z, not the official @asyncapi/parser. It implements the rules that most often break real event-driven API descriptions, and it says plainly what it does not check. Before publishing a specification, also run it through the official parser or CLI.
How to use it
- Paste an AsyncAPI document, or drop the file. Both 3.0 and 2.0 to 2.6 are recognised from the
asyncapifield. - Choose Validate and view.
- Read Findings first. Errors are broken rules, warnings are likely mistakes (such as external references that were not followed), and notes explain behaviour, such as what publish means in 2.x.
- Use the Operations, Channels, Messages and Servers tabs as documentation. Each message shows its content type, which operations use it, its payload schema and a generated example payload.
- Download the findings as CSV or the whole summary as JSON to attach to a review.
Reading the results
An error means a rule of the specification is broken in a way this validator can see: a missing info.version, a server without protocol, an unresolved $ref, a {parameter} in an address that is never declared, or - in 3.0 - an operation whose messages do not belong to its channel.
Structurally valid means none of those rules failed. It is not a certificate. The official parser also validates every object against the specification's JSON Schema, applies traits, checks bindings and follows remote references.
In 2.x the verbs are easy to misread: publish describes messages the application receives, because others publish them to the channel, and subscribe describes messages it sends. The Operations tab spells that out; 3.0 replaced the verbs with explicit send and receive actions.
Worked example: Kafka order events in AsyncAPI 3.0
The 3.0 example describes an Orders service with two Kafka servers, two channels (orderPlaced at orders.{region}.placed and paymentCaptured), two operations and two messages defined under components.
It reports 3 errors. The staging server's host uses {region} without a variables entry; the orderPlaced address uses {region} without declaring it under parameters; and the onPaymentCaptured operation receives on paymentCaptured but lists the OrderPlaced message from the other channel - 3.0 requires an operation's messages to be a subset of its channel's messages.
The Messages tab shows OrderPlaced with an example payload generated from its schema: a UUID orderId, an RFC 3339 placedAt and one line item with a quantity of at least 1. The 2.6 MQTT example is structurally valid, with one note explaining publish and subscribe.
What this validator checks - and what it does not
Checked: the asyncapi version; info.title and info.version; unknown top-level fields; every local $ref; servers (host and protocol in 3.0, url and protocol in 2.x) and their {variables}, including enum defaults; channel {parameters}; channel servers references; 3.0 operation action, channel and the messages-subset rule; reply references; 2.x operationId uniqueness; security references; security scheme type; and messages defined but never used.
Not checked: the full specification JSON Schema for every object, protocol bindings, message and operation traits, correlation IDs, schema formats other than JSON Schema (such as Avro), and external or remote files, which are listed but never fetched. For those, use the official AsyncAPI parser or CLI.
Limitations: what the result does not prove
- It is a structural validator, not the official parser; a document it accepts can still be rejected by the AsyncAPI CLI.
- Only local references are resolved. Multi-file specifications must be bundled first, or the external parts are reported as not followed.
- Example payloads are generated from JSON Schema and are only as specific as the schema; Avro, Protobuf and RAML payloads are shown but not sampled.
- YAML is read with a deliberately small reader that refuses anchors, aliases, merge keys and tags. Documents that rely on them must be expanded first.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- AsyncAPI Specification 3.0.0 - checked 19 Sep 2026
- AsyncAPI Specification 2.6.0
- AsyncAPI 3.0 migration guide
- AsyncAPI parser (official, JavaScript)
Frequently asked questions
Is this the official AsyncAPI parser?
No. The official @asyncapi/parser is a large Node library, and bundling it here was not practical. This page implements the structural rules that most often break documents, states the rest as unchecked, and should be paired with the official CLI before you publish.
What changed between AsyncAPI 2.6 and 3.0?
Operations moved out of channels into their own operations section with explicit send or receive actions, channels gained an address separate from their key, servers split url into host and pathname, messages live in a channel's messages map, and request-reply got a reply object.
Why does my 3.0 operation fail with a messages error?
In 3.0 an operation's messages must reference messages of the channel it points to, for example #/channels/orderPlaced/messages/OrderPlaced. Referencing a component message directly, or one from another channel, breaks that rule even though the message itself exists.
What do publish and subscribe mean in AsyncAPI 2.x?
They are written from the point of view of other clients. publish means others can publish to the channel, so your application receives; subscribe means others can subscribe, so your application sends. Many teams read it backwards, which is one reason 3.0 dropped the verbs.
Can it show example messages for my event documentation?
Yes. Every message with a JSON Schema payload gets an example generated from its types, formats, enums and bounds, shown next to the schema itself. Copy them into docs or tests, but treat them as illustrations rather than real events.
Does it follow $ref links to other files or URLs?
No. Only references inside the document, starting with #/, are resolved. External references are listed in a warning so you can see what was skipped. Nothing is fetched from the network.
Last reviewed by the A2Z.Tools team against the sources listed above.
