A2UI Stream Lab

v0.9 structural validator

Make agent UI renderable.

Paste an A2UI JSON or JSONL stream. Catch invalid envelopes, out-of-order surfaces, duplicate IDs, broken child references, component cycles and bad data paths before your renderer sees them.

A2UI JSON / JSONL

Validation report

{ }Paste a stream and run the validator.

Why this validator exists

Schema checks are only half the job.

A2UI is a declarative protocol for sending agent-generated interfaces to a trusted client renderer. The server streams JSON objects instead of executable UI code. That design creates a useful security boundary, but only when messages follow the protocol and the component graph remains coherent.

A single A2UI message can look valid while the complete stream is impossible to render. An updateComponents message may target a surface that was never created. A container may reference a child that never arrives. Two components may form a cycle, or an update may accidentally define the same component ID twice. This validator keeps stream state so it can report those cross-message problems.

Checks included

  • JSON object, array and JSON Lines parsing with line-specific errors.
  • Exactly one message type per envelope and no unknown envelope fields.
  • The stable v0.9 version discriminator.
  • Required surfaceId, catalogId and component fields.
  • Create, update, delete and recreate lifecycle ordering.
  • Non-empty component lists, duplicate IDs and the conventional root node.
  • Missing child references, unreachable components and graph cycles.
  • Basic RFC 6901 JSON Pointer shape for data-model updates.

The checker focuses on protocol structure and stream semantics. A custom component catalog can impose additional component properties, child fields, themes and functions. Validate against that catalog as a separate deployment step.

Workflow

From model output to a safe renderer.

  1. Generate a stream. Ask your agent for A2UI v0.9 JSONL, with one message object on each line.
  2. Validate the lifecycle. Confirm that every surface is created before component or data updates and is not recreated until deleted.
  3. Resolve the graph. Make sure a root exists and every static child ID resolves after the progressive stream is complete.
  4. Apply catalog validation. Check component-specific properties against the catalog identified by catalogId.
  5. Test in your renderer. Exercise actions, bindings, error responses and transport behavior with non-sensitive fixture data.

Focused references

Learn the parts that fail most often.

A2UI JSON validator guide

Understand accepted input formats, v0.9 envelopes and the difference between schema and semantic checks.

Read the guide →

A2UI v0.9 example

Copy an annotated create, data and component stream that follows the stable message format.

See the example →

FAQ

Before you ship.

What input formats are accepted?

You can paste a single JSON message, a JSON array of messages, or JSONL with one complete object per non-empty line.

Does A2UI require a root component?

In v0.9 the renderer starts from the component whose ID is root. The official message reference describes this as the root convention.

Are forward child references invalid?

No. Progressive rendering allows components to reference children that arrive later. This tool waits until the full pasted stream has been processed, then reports references that remain unresolved.

Is v1.0 supported?

This release targets the stable v0.9 server-to-client format. The v1.0 candidate adds protocol changes such as actionResponse; it should be validated with a version-specific checker.

Is this an official Google or A2UI project?

No. A2UI Stream Lab is an independent developer utility. The rules are based on the public specification and link back to primary documentation.