Swift AST Explorer shows the tree the Swift compiler actually parsed

A tree view for parsed Swift, not a formatter

Swift AST Explorer is a tool for visualising the abstract syntax tree of Swift source code, and it is available at swift-ast-explorer.com. The distinction from a formatter or a linter is the point. A formatter shows you the text you could write instead of the text you have, while an AST viewer shows you the tree the parser actually produced, which is a different object with different failure modes. In Swift that difference matters more than in most languages, because the compiler and the macro system work on syntax trees, and a great deal of confusion in macro development comes from a mismatch between what a developer imagines the parser saw and what it saw. The features list names three things the tool does. It presents Swift syntax in a tree structure, it maps each token in the source code to the corresponding syntax, and it provides an overview and inspection of syntax usage. The repository is a Swift package with a Sources and Tests layout, a Resources directory holding the parsers, a Public directory holding the web assets, and a webpack based front end build.

Token to node mapping is what makes it a macro tool

The middle feature is the one that matters most in practice, and it is worth being precise about what it means. Mapping every token in the source to the corresponding syntax means that the tree view is anchored to the text you pasted, so you can see which characters produced which node rather than looking at an abstract structure with no reference to the input. For macro authors that is the whole workflow. A macro receives a syntax tree and must walk it, and the two questions that consume an afternoon are which node type you actually got and where the interesting text sits inside it. A tree view that keeps the source in view answers both. It also means the tool is useful for the other common macro mistake, which is assuming that a source file and a string literal are the same thing, because a tree view makes the difference between a string literal node and a code block node immediately obvious. The tool is also useful outside macro work, as a way to see how the grammar handles a construct that you understand by intuition but not by specification.

The syntax usage overview answers a different question

The third feature is an overview and inspection of syntax usage, which is a summary view rather than a detail view, and it serves a different purpose. A tree view answers what the parser built. A usage overview answers what kinds of things appear in the code at all, and how often, which is the question you ask when you are scanning a file for a pattern rather than debugging a single construct. In practice that is the view that helps with a quick audit, for instance finding every place a particular kind of expression is used, or checking that a piece of code does not contain the construct you were worried about. The three features together cover the two modes of use people bring to an AST tool. One is the single question, where does this particular piece of syntax end up, and the other is the survey, what is in this file. The front end dependencies suggest how the overview is presented, since a table library is included alongside the editor and the styling framework, which points to a sortable list of syntax kinds rather than a chart.

A CodeMirror front end built with webpack

The web side is a separate build from the server, and the package manifest shows it as a small, modern front end stack. The editor is CodeMirror, split into the state, view, commands, language, autocomplete and legacy modes packages, all on the 6.x line, and the styling is Bootstrap with Bootstrap Icons. DataTables with the Bootstrap 5 integration is the table library, and Popper is included for the positioning behaviour Bootstrap needs. The only runtime dependency that is not a UI component is reconnecting-websocket, which tells you how the editor talks to the parser. That is a sensible choice for a tool that parses as you type, because a dropped websocket otherwise leaves the page in a state where the editor is editable but nothing is ever parsed. The build itself is webpack, with a shared configuration and separate development and production configs, and the manifest also pulls in the bundle analyzer plugin. There is a .vscode directory, a dev directory and a deploy directory, and a DEPLOYMENT.md describing how the service is put in front of users.

The container builds a separate parser for each Swift language mode

The Dockerfile is the most revealing file in the repository, because it shows how the tool supports several Swift versions at once. The build has two stages. A Node slim stage installs the front end dependencies and runs the production webpack build, producing the static assets. A Swift stage then copies that build in, resolves the Swift package, and builds the server as a release binary with a static Swift standard library. After that, the image builds one parser per language mode, each from its own package directory under the parsers resource path.

RUN swift build -c release --static-swift-stdlib --package-path Resources/parsers/50800
RUN swift build -c release --static-swift-stdlib --package-path Resources/parsers/50900
RUN swift build -c release --static-swift-stdlib --package-path Resources/parsers/51000
RUN swift build -c release --static-swift-stdlib --package-path Resources/parsers/60000

The list continues through the 6.0 series and ends with a trunk build, so the tool can parse code written against any of those language modes and let you compare how the grammar changed between them. That is more than a compatibility convenience. The Swift 5.8 to 6.0 transition changed macro behaviour in ways that are hard to reason about from documentation, and having both parsers available side by side is how you would check whether a difference you are seeing comes from the language or from your code. The image also handles the Font Awesome registry through a build argument and a temporary npm configuration, so the icon assets are fetched at build time rather than committed.

Swift 5.8 on the badge, Swift 6.4 in the image

There is a mismatch worth noticing between the badges and the build. The project badge advertises Swift 5.8 compatibility, while the Dockerfile builds on a Swift 6.4 image, and the deployment is described as macOS and Linux. The badge is likely a statement about the minimum Swift version a contributor needs rather than about the runtime, but either way it is the kind of detail that bites when you set up a local development environment. The repository has a Package.swift and a Package.resolved, a build script for the parsers, and a test directory, and the Docker build is the supported route to a running instance because the front end has to be compiled before the server can serve it. The author is Kishikawa Katsumi, who is also the maintainer of the surrounding Swift tooling, and the project is released under the Apache License 2.0 with a code of conduct, a security policy and a deployment guide. There are no GitHub releases, so the live site and the default branch are the two versions you have to work with.

Editorial conclusion

Swift AST Explorer earns a place for anyone working on Swift macros, where the whole problem is knowing what tree the macro is handed rather than what text the user typed, and for anyone learning the grammar by looking at it instead of guessing. It is a hosted tool first, and a self hosted one second, since the deployment is a container image built for Linux while the project badge lists macOS and Linux as the supported systems. Verify three things before you rely on it: that the language mode selected in the interface matches the Swift version of the code you are pasting, since the container builds a separate parser for each mode from 5.8 through 6.x and trunk, that the version of the tool you reach online is the version you need, since the repository publishes no releases, and whether the code you paste leaves your machine, because the tool is a website that parses code you give it. The licence is Apache-2.0 and the last push was on 2026-10-20.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Project website
4. README
5. SwiftFiddle/swift-ast-explorer on GitHub