Generate & Validate
GraphQL Schemas

GraphQL SDL in four steps

No account. No upload. No nonsense.

Related JSON tools

Common questions answered

What is GraphQL schema validation?

GraphQL schemas define the types, queries, mutations, and subscriptions available in a GraphQL API. Schema validation checks that your SDL (Schema Definition Language) is syntactically correct and internally consistent — all referenced types exist, field types resolve properly, and directives are applied correctly. Catching errors before deployment prevents runtime failures in production.

This tool validates GraphQL schema definitions by parsing the SDL syntax and checking for common errors like missing type definitions, duplicate field names, and invalid directive usage. Paste your schema SDL to get instant feedback with line-level error reporting. This is particularly useful when editing schemas by hand or merging fragments from multiple services in a federated architecture.

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

type Post {
  id: ID!
  title: String!
  author: User!
}

✓ Valid GraphQL Schema
  Types: User, Post
  Fields: 7 total
  Relations: User → Post
    (1-to-many)

Get the most out of this tool

• Validate schema changes locally before pushing to your GraphQL gateway to catch merge conflicts early.
• Check for duplicate type names when combining schemas from multiple microservices in a federated setup.
• Use this tool to quickly verify schema SDL snippets from documentation before integrating them.

Understanding GraphQL schema generation from JSON

GraphQL uses a strongly-typed schema language (SDL — Schema Definition Language) to describe API data shapes. Unlike REST APIs where the response structure is implicit and documented externally, GraphQL APIs require every type to be explicitly defined before the server can respond to queries. Generating a GraphQL schema from JSON response data jump-starts this type definition process by inferring types from actual response examples.

The SDL type mapping from JSON follows clear rules: JSON strings become String, JSON numbers become Int or Float (based on whether the number has a decimal component), JSON booleans become Boolean, JSON null indicates that a field is nullable (the type is not marked with !), JSON objects become GraphQL types, and JSON arrays become GraphQL list types (enclosed in []). Fields that are never null in the sample data are marked non-nullable with !.

GraphQL's non-null modifier (!) is a critical design decision. In GraphQL, all fields are nullable by default — a field marked String can return either a string or null. Adding ! makes the field non-nullable: String! guarantees the resolver will always return a string. Schema-first design typically marks required fields as non-nullable, which communicates the contract to clients and enables stricter code generation. Over-using nullable fields produces schemas that force clients to check for null everywhere.

Naming conventions in GraphQL SDL differ from JSON conventions. GraphQL type names use PascalCase (e.g., UserProfile), while field names use camelCase (e.g., firstName). JSON keys may use snake_case (e.g., first_name) or camelCase depending on the backend language. When generating a GraphQL schema from snake_case JSON, the generator should convert key names to camelCase to follow GraphQL conventions — with @deprecated directives or resolver mapping for backward compatibility.

The ID scalar type in GraphQL represents unique identifiers. While ID is serialized as a string in JSON, it semantically differs from a plain String — IDs are typically opaque, not human-readable, and not intended for display. A smart schema generator detects fields named id, _id, or matching the pattern *Id and maps them to the ID scalar rather than String, improving the generated schema's semantic accuracy.

Custom scalars extend GraphQL's built-in type system for domain-specific values. The Date, DateTime, URL, Email, and JSON scalars are common additions. The built-in GraphQL scalars (String, Int, Float, Boolean, ID) cannot represent ISO 8601 date strings with semantic date meaning — a DateTime custom scalar allows clients to know that a value is a date and enables date-aware code generation. Schema generators often detect ISO date strings and suggest custom scalar types.

Schema stitching and federation extend generated schemas to compose multiple GraphQL services into a unified graph. Apollo Federation allows each service to own part of the schema and declare references to types owned by other services using @key directives. A generated schema from one service's JSON output is a starting point — federation directives, resolver implementations, and type references to other service schemas must be added manually to complete the federated type definitions.

When GraphQL schema generation from JSON is useful

GraphQL schema design pitfalls

• Making all fields nullable out of caution: Nullable fields force clients to check for null before using every value, producing defensive code full of null checks. Make fields non-nullable (String!) when you can guarantee they will always have a value. Reserve nullable for fields that legitimately may be absent.
• Using String for everything: Generated schemas from JSON sometimes map all values to String when the JSON samples happen to have string representations of what should be typed values. Use Int for integers, Float for decimals, Boolean for flags, and custom scalars for dates and URLs to enable type-safe client code generation.
• Not extracting reusable types: If the same object structure appears multiple times in a JSON response (e.g., a user object in multiple places), the schema should define one User type used everywhere — not duplicate inline type definitions. Review generated schemas for structural repetition and consolidate into shared types.
• Generating from unrepresentative samples: A schema generated from one API response sample may miss optional fields that appear only in some responses, union type variants for polymorphic fields, and edge case types for empty arrays. Generate from multiple diverse samples and merge the resulting schemas to improve coverage.

Additional frequently asked questions