Prisma Schema Formatter
Format a Prisma schema the way prisma format does — fields aligned into columns — and catch duplicate fields and models with no identifier.
schema.prisma
Formatted
2 models · 11 fields · 1 relationsgenerator client {
provider = "prisma-client-js"
}
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
model User {
id Int @id @default(autoincrement())
email String @unique
name String?
role Role @default(USER)
posts Post[]
createdAt DateTime @default(now())
}
model Post {
id Int @id @default(autoincrement())
title String
published Boolean @default(false)
author User @relation(fields: [authorId], references: [id])
authorId Int
@@index([authorId])
}
enum Role {
USER
EDITOR
ADMIN
}
Checks
No problems found — 2 models, 1 enums, 1 indexes.
Formatting happens in your browser. A schema file contains your data model and often a connection string — this Prisma formatter never uploads either.
About the Prisma Schema Formatter
This Prisma formatter does what `prisma format` does — aligns every field name, type and attribute into columns — plus the checks that catch a schema which will not generate. It runs entirely in your browser, which matters here because a schema file usually sits next to a connection string.
The alignment is the point. Prisma's own formatter lines each block up into three columns, so a schema that has been hand-edited since the last run is visibly ragged and produces a noisy diff full of whitespace changes. The rule is mechanical, which is why the output is exactly reproducible and why doing it by hand is tedious enough that people skip it.
Alongside formatting it reports what would stop `prisma generate`: a model with no @id, @@id, @unique or @@unique; a field or model declared twice; a second datasource block; an unclosed brace, with the line it opened on. Warnings are separated from errors, so a missing identifier is not presented as equivalent to a syntax error.
What it is not is a full Prisma parser. It knows the block-and-attribute grammar, not which native types your provider supports or whether a relation resolves on the other side. Everything it reports it can prove from the text.
- Column alignment for field names, types and attributes, matching prisma format
- The = signs in datasource and generator blocks aligned too
- Comments preserved in place, including /// doc comments and end-of-line ones
- Optional alphabetical field sort that moves a field's comment along with it
- Errors for duplicate fields, duplicate models, unclosed blocks and stray braces
- Warnings for a model with no unique identifier, an empty enum, a datasource with no url
- Model, field, relation and index counts
How to use it
- Paste the contents of your schema.prisma file into the left pane.
- Read the Checks panel. Errors will stop prisma generate; warnings will not, but a model with no identifier is one Prisma refuses outright.
- Leave Align columns on unless you have a reason not to — it is what makes the output match what prisma format would produce.
- Sort fields A–Z is off by default, because field order is author intent and reordering it produces a large diff for no functional gain.
- Copy the formatted schema back over your file.
Real-world use cases
Backend developers without Prisma installed locally
Format or sanity-check a schema.prisma pasted from a PR, a Slack message or a template repo, without npm installing Prisma into a project just to run one command.
Reviewers on a pull request
Paste the diff's schema into the checker to confirm a model still has a unique identifier and no field was accidentally duplicated during a merge, without pulling the branch locally.
Developers learning Prisma
See immediately why a hand-written model won't generate — a missing @id is the single most common first mistake — with the reason stated in plain language rather than the CLI's validation error.
Engineers doing a one-off fix
Clean up alignment on a schema edited outside an IDE — over SSH, in a GitHub web edit, on a machine without the Prisma CLI — where running the real formatter isn't practical for a single change.
Teams standardizing schema style
Check that a schema matches prisma format's column-alignment convention before it's committed, catching the ragged whitespace diffs that show up when someone edits a model by hand and skips the formatter.
Examples
Alignment
model User {
id Int @id @default(autoincrement())
email String @unique
name String?
}model User {
id Int @id @default(autoincrement())
email String @unique
name String?
}Three columns: name, type, attributes. Widths come from the longest entry in the block.
The = in a datasource
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}Assignments get their own alignment pass, on the key rather than on three columns.
A model Prisma will reject
model Session {
token String
userId Int
}Warning, line 1: Model "Session" has no unique identifier.
Prisma requires @id, @@id, @unique or @@unique on every model. This one formats cleanly and still will not generate.
A multi-line block attribute
@@unique([ authorId, slug ])
@@unique([ authorId, slug ])
Attributes whose brackets span lines are joined back onto one line, which is where prisma format puts them.
Common errors
| Message | Cause | Fix |
|---|---|---|
| Error validating model "X": Each model must have at least one unique criteria | No field carries @id or @unique, and the model has no @@id or @@unique block attribute. | Add @id to the primary key field, or @@id([a, b]) for a composite key. Reported here as a warning before you run generate. |
| Error parsing attribute @relation: The relation field ... is missing an opposite relation field | A relation is declared on one model only. Prisma relations are always declared on both sides. | Add the matching field to the other model. This tool does not check relation pairing — it has no view of resolution — so run prisma validate as well. |
| Field ... is already defined on model | The same field name appears twice in one block, usually after a merge. | Reported here as an error with both line numbers, so you can see which of the two to delete. |
| Environment variable not found: DATABASE_URL | The datasource url uses env() and the variable is not set where the command is running. | Nothing to do with the schema text — set the variable, or check that .env is in the directory Prisma is invoked from. |
| Unexpected token. Expected one of: end of block | A brace was never closed, so everything after it was read as part of the block. | This tool reports the line the unclosed block opened on, which is more useful than the line the parser gave up on. |
| You cannot define more than one datasource | Two datasource blocks in one schema. Prisma allows exactly one. | Reported here as an error on the second block. Multiple databases need multiple Prisma clients, not multiple datasources. |
Frequently asked questions
›Is my schema uploaded anywhere?
No. Parsing and formatting run entirely in your browser. That is worth caring about here specifically: a schema.prisma file describes your whole data model, and the datasource block frequently has a real connection string in it rather than an env() call. Nothing on this page transmits or stores either.
›Is the output identical to prisma format?
The alignment rules are the same — three columns per model block, aligned = in datasource and generator blocks, two-space indent. Prisma's formatter is part of the engine and can also rewrite things this tool deliberately does not touch, such as adding a missing opposite relation field. Treat this as the formatting half, and run prisma format or prisma validate in CI for the rest.
›Why is sorting fields off by default?
Because field order is author intent. It is the order fields appear in generated types and in most schema documentation, and people group related fields deliberately. Sorting is offered because it is occasionally what you want on a large model, but turning it on produces a diff touching every line.
›Are my comments kept?
Yes, all of them. Line comments stay on their own line, end-of-line comments stay at the end of their field, and /// doc comments — which Prisma puts into the generated client — are preserved exactly. If you sort fields, a comment above a field travels with that field rather than being left behind.
›Does it check my relations?
No, and it says so rather than implying otherwise. Relation validation needs both sides resolved and the referenced fields checked against the other model, which is a full semantic pass. This tool checks the things it can prove from the text: syntax, duplicates, and whether a model has a unique identifier.
›Can it format a schema split across several files?
Paste one file at a time. Prisma's multi-file schema support treats each file as an independent unit for formatting, so per-file is the right granularity — but a duplicate model name across two files will not be caught here, since only one file is in view.
›Why does the alignment change when I add one long field?
Column widths are computed per block from the longest entry in it, so a single long field name or type widens the whole block. That is exactly what prisma format does, and it is why a hand-edited schema drifts out of alignment as soon as any field is renamed.
›Why use this instead of just running npx prisma format?
For most day-to-day work you shouldn't — the CLI is the source of truth and belongs in your editor's format-on-save. This exists for the moments the CLI isn't reachable: a schema pasted into a browser tab with no local Prisma install, a quick check on someone else's PR, or a one-off fix from a machine that doesn't have the project cloned. It's a narrow, honest niche rather than a replacement for the tool it mirrors.
Last updated