Standard Schema has emerged as one of those elegant solutions that makes you wonder why we didn’t have it sooner. Released in Jan, it’s already making waves across the TypeScript ecosystem by providing a unified interface for schema validation libraries.

The Validation Tower of Babel

Before diving into Standard Schema, we shall briefly recall the state of validation in the TypeScript world. We’ve had a proliferation of excellent libraries:

  • Zod with its robust type inference and composable API
  • Valibot optimized for bundle size
  • ArkType focusing on performance
  • Yup as the veteran in the space
  • io-ts with its functional approach
  • Superstruct, TypeBox, and many others

Each has its strengths, trade-offs, and passionate fan bases. But this diversity created a problem: tools and frameworks that accept schemas (like form libraries, API frameworks, or ORM query builders) had to either:

  1. Pick one winner validation library to support
  2. Build adapters for multiple libraries
  3. Create their own validation system (adding to the fragmentation!)

Standard Schema

Standard Schema is a specification that defines a common interface for TypeScript schema validation libraries. At its core, Standard Schema is beautifully simple. It defines a StandardSchemaV1 interface that validation libraries can implement:

The gist:

export interface StandardSchemaV1<Input = unknown, Output = Input> {
  readonly '~standard': {
    readonly version: 1;
    readonly vendor: string;
    readonly validate: (value: unknown) => Result<Output> | Promise<Result<Output>>;
  };
}

export type Result<T> = 
  | { value: T; issues?: undefined } 
  | { value?: undefined; issues: any[] };

The tilde prefix (~standard) is a clever touch that both avoids naming conflicts and deprioritizes these properties in IDE autocompletion.

Colin McDonnell, the creator of Zod, announced Standard Schema 1.0 as a proposal “for a standard interface to be adopted across TypeScript validation libraries.” The goal is elegant: make it easier for libraries to accept user-defined schemas as part of their API, regardless of which validation library created them.

How It Works In Practice

Let’s say we’re building a form library. Instead of tying it to a specific validation library, we can accept any schema that implements the Standard Schema interface:

function validateForm<T>(
  schema: { readonly '~standard': { validate: (value: unknown) => any } },
  formData: unknown
): ValidationResult {
  const result = schema['~standard'].validate(formData);
  // Process result consistently regardless of the schema library
  return transformToFormErrors(result);
}

Now users can bring their preferred validation library:

// With Zod
import { z } from 'zod';
const zodSchema = z.object({
  username: z.string().min(3),
  age: z.number().min(18),
});
validateForm(zodSchema, formData);

// With Valibot
import * as v from 'valibot';
const valibotSchema = v.object({
  username: v.string([v.minLength(3)]),
  age: v.number([v.minValue(18)]),
});
validateForm(valibotSchema, formData);

The example work seamlessly because both Zod and Valibot have implemented the Standard Schema interface.

The Ecosystem Impact

What has made Standard Schema so successful in such a short time is its rapid adoption by major libraries. As of now:

  • Zod has it built-in as of v3.22
  • Valibot added support in v0.25
  • ArkType implemented it natively
  • Adapters exist for Yup, io-ts, and others

This widespread adoption means that tools built on Standard Schema can immediately support a wide range of validation libraries. We’ve already seen this with:

  1. Form libraries like React Hook Form and Formik adding Standard Schema support
  2. API frameworks like tRPC and NestJS embracing the standard for input validation
  3. ORMs using it for query builders and input validation
  4. Testing tools leveraging it for property-based testing

Empowering End-User Developers

For end-user developers, Standard Schema offers several practical advantages:

1. Freedom to Choose the Right Tool

Different validation libraries excel in different areas. With Standard Schema, you can select libraries based on:

  • Bundle size: Choose Valibot for client-side code where every kilobyte matters
  • Performance: Use ArkType where validation speed is critical
  • Feature richness: Leverage Zod’s comprehensive API when needed
  • Team familiarity: Use what your team already knows best

All without being locked into a single vendor throughout your application.

2. Simplified Experimentation

Want to try out a new validation library? Before Standard Schema, this meant:

// Before Standard Schema - Parallel implementations
const zodSchema = z.object({ /* ... */ });
const valibotSchema = v.object({ /* ... */ });
const arkTypeSchema = t.object({ /* ... */ });

// Different validation calls for each library
function validateWithZod(data) { /* ... */ }
function validateWithValibot(data) { /* ... */ }
function validateWithArkType(data) { /* ... */ }

Now, you can simply:

// Create schemas with different libraries
const schema1 = z.object({ /* ... */ });
const schema2 = v.object({ /* ... */ });
const schema3 = t.object({ /* ... */ });

// One validation function for all
function validate(schema, data) {
  return schema['~standard'].validate(data);
}

This drastically reduces the cost of trying new tools and approaches.

3. Future-Proofing Your Codebase

Technologies evolve rapidly, and yesterday’s popular library might be tomorrow’s legacy code. By adopting Standard Schema, you’re building in an escape hatch for future migrations:

// Your application code remains stable
app.post('/users', validateBody(userSchema), createUser);

// The implementation of userSchema can change over time
// From Zod in 2024:
const userSchema = z.object({ /* ... */ });

// To whatever comes next in 2026:
const userSchema = nextGenValidator.object({ /* ... */ });

Your core application logic remains unchanged even as validation libraries evolve.

Moving Forward with Standard Schema

Standard Schema represents a significant shift in how we approach validation in the TypeScript ecosystem. By focusing on interoperability rather than creating yet another validation library, it multiplies the value of existing tools and reduces fragmentation.

If you’re building libraries or frameworks that accept schemas, supporting Standard Schema means instantly supporting all compatible validation libraries with minimal code. The investment is small, but the value to your users is substantial.

For application developers, there’s virtually no downside. Use your preferred validation library that implements Standard Schema, and you’ll gain flexibility for future migrations while ensuring better integration with a growing number of tools and frameworks.

Those creating validation libraries should consider implementing the interface. It’s often just a few lines of code to make your library instantly compatible with an expanding ecosystem of tools.

What makes Standard Schema particularly promising is that it represents a more collaborative approach to solving common problems. For the TypeScript ecosystem that has sometimes struggled with fragmentation, it offers a glimpse of a more cohesive future, one built on cooperation rather than just competition.

Standard Schema may be simple in implementation, but its impact on how we build TypeScript applications is potentially profound. And that’s something worth validating.