JSON to Prisma Schema — Infer a Model
Turn a JSON array of objects into a Prisma model — field types inferred from your data, optional (?) where a value can be missing, and an id primary key detected automatically.
From a JSON sample to a Prisma model
Have an API response or a seed file and want a Prisma model to store it? This tool reads a JSON array of objects and writes the model block to hold it. Every key becomes a field, and its type is inferred from the actual values across all records: whole numbers become Int (or BigInt when a value is too large for 32 bits), decimals become Float, true/false become Boolean, text becomes String, and nested objects or arrays become Json.
Optionality & the id, inferred honestly
A field is required only when every record supplies a non-null value; the moment one record omits the key or holds null, the field gets a trailing ?. If a field called id is an integer that is always present, it becomes @id @default(autoincrement()). When the data doesn't justify a constraint, the tool leaves it off rather than guess — you stay in control of what the schema promises.
Finish the schema
The generated model is a strong first draft: add your datasource and generator blocks, relations between models, indexes and defaults before running prisma migrate. Need SQL instead? JSON to SQL Schema builds a CREATE TABLE, and JSON to TypeScript generates matching interfaces. Reshape the JSON first with JSON Flatten if you need nested fields as their own columns.
Frequently asked questions
How are Prisma field types inferred?
Every value in a field is scanned across all records. All-integer fields become Int (or BigInt beyond the 32-bit range), decimals become Float, true/false become Boolean, strings become String, and nested objects or arrays become Json. A field mixing incompatible types widens to String.
How is optionality decided?
A field is required only when the key is present in every record and never null. If any record omits it or has a null value, the field is marked optional with a trailing ? — the safe default.
Where does the @id come from?
If a field named "id" is an integer that is always present and never null, it becomes @id @default(autoincrement()); a non-null string id becomes @id. No suitable id means the model is emitted with a note reminding you Prisma needs an @id.
What about field names that are not valid identifiers?
A JSON key with characters Prisma does not allow (dots, dashes, leading digits) is turned into a valid field name and given an @map("original-key") so it still maps to your column. Relations and indexes are yours to add.
Is the schema ready to use as-is?
Treat it as a strong starting point. Types are inferred from a sample, so review them against production data, add relations, indexes and a datasource/generator block. Everything is generated in your browser; nothing is uploaded.