GraphQL Schema Visualizer

A GraphQL schema written in SDL (Schema Definition Language) declares every type your API exposes and how those types reference one another. As a schema grows, the web of relationships — which type points at which — becomes the hard part to hold in your head. This visualizer parses the SDL and surfaces both the type list and the relationship edges between types.

How it works

The parser first strips descriptions and comments, then extracts definitions with a lightweight tokenizer:

1. type, interface, and input blocks are read along with their { ... } field bodies; each field’s return type is captured.
2. enum, union, and scalar definitions are collected with their symbols or members.
3. For every field whose return type — once stripped of list [ ] and non-null ! wrappers — names another defined type, an edge From.field → To is recorded.

The set of edges is the adjacency list of the schema’s relationship graph: walk it to see how data connects from the root Query outward.

Worked example

Given a sample blog schema:

type User {
  id: ID!
  name: String!
  posts: [Post!]!
}

type Post {
  id: ID!
  author: User!
  comments: [Comment!]
  title: String!
}

type Comment {
  text: String!
  author: User!
}

The visualizer extracts:

Fields returning built-in scalars (ID, String, Boolean, Int, Float) produce no edges because they are leaf types with no further structure. The resulting graph shows, for example, that User and Post are mutually connected — a bidirectional relationship that can affect query depth and N+1 loading strategy.

Why relationship edges matter

When you see a cycle in the edge graph — such as User → Post → User — you know recursive queries are possible and that you need a depth limit or persisted query strategy to avoid runaway execution. When a type appears as a destination in many edges (high in-degree), it is a central “hub” type that is frequently joined to: make sure its resolver is efficient and consider DataLoader batching.

A type with no outgoing edges to other defined types is a pure leaf — no joins, no DataLoader needed. Visually auditing which types are hubs and which are leaves is the practical use case this tool enables.

Common patterns in real schemas

Interface implementations appear as types that share a common interface. The visualizer lists these as separate nodes, but you can spot them by interface keywords in the type list — useful for confirming that all implementing types cover the expected interface fields.

Union members appear as distinct edges from union to each member type. A search union returning BlogPost | VideoPost | PodcastEpisode shows three outgoing edges from the union, which maps to the three fragments a client needs to handle.

Input types appear in the type list but rarely produce outgoing edges, since input types reference other input types mainly for nested arguments. They are useful to track for mutation argument shape.

Notes

The tool also flags any field that references a name which is neither a built-in scalar nor a defined type, catching typos and missing definitions early. It maps structure, not behavior, so it does not execute queries or validate resolver logic — it is a fast way to understand and audit how a schema’s types relate.

Your schema is parsed entirely in your browser and never transmitted to a server, so it is safe to paste internal or private schemas.