b2KIT

AST Explorer

Parse JavaScript, TypeScript, or Python into an abstract syntax tree and explore nodes interactively.

Tested tool guide Tested browser tools Checked August 15, 2026

What AST Explorer does, with a checked example

Paste a snippet of JavaScript, TypeScript, or Python and this tool runs it through that language's parser to produce that parser's abstract syntax tree, then lets you click through nodes to see their type and fields. People often assume there is one universal AST shape; in practice Babel, Acorn, and the TypeScript compiler emit different node names and structures for the same JavaScript, and Python's ast module is a different format again, so a tree that looks right here may not match what your target library actually consumes.

Worked example

A concrete input and expected output from the current implementation.

Input

const x = 1;

Expected output

Program
└─ VariableDeclaration (kind: "const")
   └─ VariableDeclarator
      ├─ id: Identifier (name: "x")
      └─ init: Literal (value: 1, raw: "1")

A const declaration parses as one VariableDeclaration statement holding one VariableDeclarator, whose id is the bound identifier x and whose init is the literal 1 this ESTree-style layout is what Acorn- and Espree-based tools produce for this line.

How the result is produced

1

Language-specific parsing

Input is routed to a parser for the selected language rather than one generic engine: an ESTree-based parser for JavaScript, a TypeScript-aware variant for .ts/.tsx syntax (types, interfaces, generics), and Python's own grammar for Python. Each follows that language's actual grammar, so the resulting node types and fields differ between languages even for structurally similar code.

2

Interactive node inspection

The tree renders as an expandable outline; selecting a node shows its type and properties (e.g. kind, name, value, operator) and typically highlights the matching span in the source pane. Expanding deeply nested nodes (chained calls, nested JSX, comprehensions) requires opening each level manually, since the tree starts collapsed or partially collapsed for readability.

Good uses

  • Checking the exact node type and property names for a construct (e.g. optional chaining, a Python walrus assignment) before writing an ESLint rule, Babel plugin, or Python ast.NodeVisitor against it
  • Debugging why a codemod or regex-based find-and-replace mis-handles an edge case, by seeing how that edge case is actually structured in the tree
  • Learning how a language feature is represented in the parse tree, such as how destructuring, decorators, or async/await appear and nest as syntax nodes, as distinct from how a later compiler pass might desugar or lower them

Limits and checks

  • The same JavaScript can produce differently-shaped trees in Babel, Acorn/Espree, and the TypeScript compiler; this tool's output matches whichever parser it uses, which may not be the one your target library uses
  • Parsing mode matters: module vs. script context, JSX enabled or not, and TypeScript-specific syntax can change whether code parses at all or what node types appear for the same source
  • The tool requires syntactically complete, valid code; a snippet that is deliberately partial (a dangling clause, an unterminated block) will typically fail to parse rather than produce a partial tree

Common questions

Will this match the AST my ESLint or Babel plugin actually receives?

Only if it uses the same underlying parser. ESLint's default parser (Espree) and Babel's parser both produce ESTree-like trees but diverge on newer or TS-specific syntax, and the TypeScript compiler's own AST is structurally different again. Treat this as a guide to shape and node names, then confirm against your specific toolchain's parser output.

Can I paste an incomplete fragment, like just an expression or a function body missing its closing brace?

A single expression (like 1 + 2) usually parses fine since it's still valid syntax. A truly incomplete fragment, such as an unterminated block or a dangling operator, will not parse; most parsers require syntactically complete, balanced code and report a syntax error instead of a partial tree.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools