JSON Input

GraphQL Schema (SDL)

What is JSON to GraphQL Schema Generator?

GraphQL describes an API with a strongly typed schema written in SDL (Schema Definition Language). This tool reads a JSON sample and generates the SDL type definitions that describe its shape — one type block per object, with each field given a GraphQL scalar (String, Int, Float, Boolean, ID) or a reference to another generated type. The single most important concept the generator has to get right is nullability, and it is the opposite of what JSON expresses. In GraphQL every field is nullable by default; you make a field non-null by appending an exclamation mark — String! means "always present, never null". JSON has no such marker, so the generator infers it: a field that is present and non-null in your sample is a candidate for non-null, while a field that appears as null becomes plainly nullable. Because the exclamation mark is a hard contract that clients rely on, you should review every ! the generator emits against what your resolver can actually guarantee. The other distinction that trips people up is Input types versus Object types. The types this tool generates are output (Object) types — the shape your API returns. GraphQL forbids using an Object type as an argument; mutation arguments must use a separate input type declared with the input keyword. So the generated types describe your query responses, and you typically hand-write matching input types for your mutations. Anything that is not a String, Int, Float, Boolean, or a nested object — dates, money, UUIDs — has no built-in scalar and should be modeled as a custom scalar.

How to Use

Name the root type in PascalCase to match GraphQL convention (e.g. "User", "Product"); nested objects are emitted as their own PascalCase types automatically
Paste a fully populated sample so the generator can tell which fields are reliably present — fields it sees as non-null become candidates for the non-null (!) marker
After generating, audit every ! against your resolvers: mark a field non-null only if the resolver can ALWAYS return a value, because a null on a non-null field errors the whole response
Replace String placeholders for dates, money, and UUIDs with custom scalars (scalar DateTime, scalar Decimal) and declare them at the top of your schema
Hand-write matching input types for any mutation arguments — the generated Object types cannot be reused as arguments

Why Use This Tool?

Generates valid SDL type definitions with one type block per nested object

Infers GraphQL scalars (String, Int, Float, Boolean) from real JSON values

Proposes the non-null (!) marker for fields that are present and non-null in the sample

Resolves nested objects into separate, referenced types so the schema stays normalized

Produces output (Object) types you can drop into a schema-first GraphQL server

Tips & Best Practices

String! and String are NOT interchangeable: ! is a promise to the client that the field is never null. If a resolver returns null for a non-null field, GraphQL nullifies the parent (or the whole query) and emits an error — so only mark ! what you can guarantee
A non-null list and non-null items are two different things: [Post!]! means the list itself is never null AND no element is null; [Post]! means the list is present but may contain null elements. Pick the right combination for partial-failure tolerance
GraphQL has no Date, DateTime, JSON, or BigInt scalar built in — these come out as String. Declare custom scalars (scalar DateTime) and wire a serializer in your server, otherwise clients lose type information
Use the ID scalar, not String, for identifiers. ID serializes as a string but signals "opaque key" to clients and tooling; the generator emits String for an id field, so switch it to ID by hand
The generated types are output types only. Trying to pass one as a mutation argument fails schema validation — duplicate the shape into an input MyTypeInput { ... } block for arguments

Frequently Asked Questions

What is the complete JSON to GraphQL type mapping?

JSON string → String (switch to ID for identifiers, or a custom scalar like DateTime for dates). JSON integer → Int (GraphQL Int is a signed 32-bit value; use a custom BigInt scalar for larger numbers). JSON float → Float. JSON boolean → Boolean. JSON null → the field is left nullable (no ! marker). JSON array → a list type [T], where T is the element type and may itself be non-null. JSON nested object → a separate, referenced Object type. Fields that are present and non-null in the sample are proposed with the non-null marker, e.g. String!.

What does the exclamation mark (!) mean and when should I use it?

The ! makes a field non-null — a contract that the field is always present with a non-null value. Clients can then safely use it without null checks. Use it only when the underlying resolver can guarantee a value (e.g. a primary key, a required column). If a non-null field ever resolves to null at runtime, GraphQL propagates the error up to the nearest nullable parent and may null out the entire response, so over-marking ! makes your API brittle.

What is the difference between an Object type and an Input type?

An Object type (declared with the type keyword) describes data your API RETURNS — query and mutation responses. An Input type (declared with the input keyword) describes data a client SENDS as field arguments, typically for mutations. GraphQL deliberately keeps them separate: you cannot use an Object type as an argument, and input types cannot have resolvers or interfaces. This tool generates Object types; you write the matching input types for your mutations.

How do I represent dates, money, or other non-standard values?

GraphQL only ships five built-in scalars (Int, Float, String, Boolean, ID), so dates, timestamps, decimals, UUIDs, and arbitrary JSON have no native type and arrive as String. Define a custom scalar — scalar DateTime, scalar Decimal, scalar JSON — at the top of your schema and implement its serialize/parseValue functions (or use a library like graphql-scalars). Then replace the String placeholder with the custom scalar in the generated type.

How are nested objects and arrays of objects handled?

Each distinct nested object becomes its own named Object type, and the parent references it by name, keeping the schema normalized rather than deeply inlined. An array of objects becomes a list of that type, e.g. posts: [Post!]!. The generator names nested types from their field key in PascalCase; you may want to rename them to avoid collisions when two different parents have a field with the same name but a different shape.

Is my data sent to a server?

No. SDL generation runs entirely in your browser. Your JSON never leaves your device.

Real-world Examples

User type with a non-null ID and an optional field

A user payload where id and email are always present (good candidates for non-null) but bio came back null (so it stays nullable). After generating, id is switched from String to the ID scalar and createdAt to a custom DateTime scalar — both manual edits the generator cannot infer.

Input

{
  "id": "u_1",
  "email": "[email protected]",
  "displayName": "Ada",
  "bio": null,
  "isAdmin": false,
  "createdAt": "2024-01-01T00:00:00Z"
}

Output

scalar DateTime

type User {
  id: ID!
  email: String!
  displayName: String!
  bio: String
  isAdmin: Boolean!
  createdAt: DateTime!
}

Nested object plus a non-null list of objects

A blog post embeds an author object and a tags array of objects. The author becomes its own Author type; tags becomes a non-null list of non-null Tag values, [Tag!]!, meaning the array is always present and never contains null entries.