json to graphql schema (sdl) converter
typetools
instant, client-side type converter • 0ms network latency
type Metadata {
lastLogin: String!
ipAddress: String!
failedAttempts: String
}
type RootPayload {
userId: String!
username: String!
email: String!
isActive: Boolean!
score: Float!
roles: [String!]!
metadata: Metadata!
tags: [String!]!
}step-by-step integration guide
technical specification differences & end-to-end conversion workflow
Architectural Contrast Between REST JSON Payloads and GraphQL SDL
GraphQL enforces a strongly typed, hierarchical contract between client and server using the GraphQL Schema Definition Language (SDL). Unlike JSON, which is an untyped data interchange format where objects are anonymous key-value maps, every nested object in a GraphQL API must be declared as a named type with explicitly typed fields. Furthermore, GraphQL distinguishes between 32-bit signed integers (Int) and IEEE 754 double-precision floating-point values (Float), provides a dedicated scalar for unique identifiers (ID), and uses postfix exclamation marks (!) to enforce non-nullability on both scalar fields and list wrappers (e.g., [User!]!).
Recursive Object Type Extraction and Non-Null (!) Inference
When you paste a complex JSON response into our converter, the AST engine traverses the tree bottom-up to hoist every nested JSON object into its own named GraphQL type declaration in PascalCase. For each property, the analyzer infers the most specific GraphQL built-in scalar: fields named id, _id, or uuid are promoted to the ID scalar; whole numbers map to Int; decimals map to Float; and booleans map to Boolean. When analyzing arrays of objects, the engine merges all observed fields across sibling elements: fields that are guaranteed to be present and non-null receive the strict ! non-null modifier (e.g., email: String!), while nullable or sparse fields omit the ! to prevent GraphQL resolver execution errors when upstream data is missing.
frequently asked questions
common developer questions answered
q:What is the difference between [String], [String!], and [String!]! in the generated GraphQL schema?
[String] allows both the list itself and its items to be null; [String!] guarantees non-null items inside a nullable list; and [String!]! guarantees that both the list and every element inside it are never null.
q:Why does GraphQL not allow arbitrary untyped JSON objects as a field type?
The GraphQL specification requires clients to select explicit sub-fields on every non-scalar type. Our converter automatically extracts nested JSON objects into named GraphQL Object Types so queries can select their nested fields.
q:How are JSON numbers larger than 32-bit signed integers handled in GraphQL?
GraphQL's built-in Int scalar is strictly limited to 32-bit signed integers (±2.14 billion). Numbers exceeding 32-bit bounds are promoted to Float or String/custom BigInt scalars to avoid GraphQL serialization overflow errors.