Skip to content

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 relations
generator 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

  1. Paste the contents of your schema.prisma file into the left pane.
  2. Read the Checks panel. Errors will stop prisma generate; warnings will not, but a model with no identifier is one Prisma refuses outright.
  3. Leave Align columns on unless you have a reason not to — it is what makes the output match what prisma format would produce.
  4. 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.
  5. 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

Input
model User {
id Int @id @default(autoincrement())
email String @unique
name String?
}
Output
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

Input
datasource db {
provider = "postgresql"
url = env("DATABASE_URL")
}
Output
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

Input
model Session {
  token String
  userId Int
}
Output
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

Input
@@unique([
  authorId,
  slug
])
Output
@@unique([ authorId, slug ])

Attributes whose brackets span lines are joined back onto one line, which is where prisma format puts them.

Common errors

MessageCauseFix
Error validating model "X": Each model must have at least one unique criteriaNo 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 fieldA 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 modelThe 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_URLThe 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 blockA 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 datasourceTwo 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