JSON → GraphQL Type Definitions

Overview

Generates GraphQL type definitions from a JSON object: strings map to String, integers to Int (Float beyond the 32-bit range), decimals to Float, booleans to Boolean, nested objects to their own named types, arrays to list types, and only null, mixed or empty values to the JSON scalar. The output is a Root type plus one type per nested object, ready to paste into a schema. Conversion is live and click-to-copy.

How It Works

Paste a JSON object into the input panel. Each key becomes a field in a type Root block (nested objects get their own type blocks, named after their key), with the GraphQL type chosen from the value's runtime type: whole numbers become Int (or Float beyond the 32-bit range), numbers with a fractional part become Float, text becomes String, and true or false become Boolean. Objects become named types, arrays become lists such as [String], and null, mixed or empty-array values become JSON, with a scalar JSON line added automatically when it is used. The generated block appears immediately and copies on click.

Step-by-Step Usage Guide

1. Paste a JSON object that represents one example of your entity.
2. Read the generated type blocks, checking which fields became JSON scalars (null, mixed or empty values).
3. Refine fields by hand where a null, mixed or empty value needs a real type.
4. Rename the Root type to your entity's name and paste it into your schema.

Technical Specifications & Standards

The mapping reflects what can be inferred from one example value, with two consequences that show up in real schemas. First, the JSON scalar is only a fallback: nested objects become their own types and arrays become lists (a tags array becomes tags: [String]), but a null, mixed-type or empty-array value has no inferable type and is emitted as JSON, which is not part of the GraphQL specification; it is the de facto custom scalar from the graphql-type-json ecosystem. The tool prepends a scalar JSON line when it is used, but your server still needs an implementation of that scalar, and you should hand-refine those fields. Second, every field is emitted without an exclamation mark, which in GraphQL semantics means all fields are nullable: a null value, a missing key, or an error makes the field null rather than failing the resolution. There is no input-type distinction either, so the output is a query-side type, not an input declaration. Int versus Float follows JavaScript's number model: 2 yields Int and 2.5 yields Float, and 2.0 in JSON parses to the integer 2 and therefore emits Int; integers beyond the 32-bit range become Float. The top-level type is always named Root regardless of your domain, so rename it in your schema; nested types are named from their keys, and enums or unions cannot be inferred from example values.

Targeted Use Cases

• Bootstrapping schema types from a sample API response during design.
• Discussing nullability and scalar choices with a team using concrete inferred types.
• Generating a starting SDL for a mock server from example data.
• Teaching how GraphQL's scalar system maps, and fails to map, onto JSON values.

Notes & Gotchas

• Implement the JSON scalar on your server if any field uses it (the tool adds the scalar JSON declaration), since it is not a built-in GraphQL type.
• Replace JSON-typed fields with proper types before shipping; they appear only where the sample had null, mixed or empty values.
• Add exclamation marks deliberately after reviewing which fields must be non-null; every generated field is nullable.
• Rename the generated Root type; the tool always uses that name regardless of your domain.

Frequently Asked Questions