Export `binary` string OpenAPI types using `z.file()` in zod v4

[ntjess]

Description

Zod 4 now supports z.file() natively, which means OpenAPI specs referencing a Blob | File can have parity between zod/ts generation.

Current behavior is z.string(), which doesn't match the typescript definitions.

Hopefully this is a straightforward task especially if zod 4 is targeted by default.

[mrlubos]

Do you want to open a pull request for this change? You may also want to read #1616 for additional context around this request, it's very similar

[ntjess]

Thanks for linking the context. Indeed, it brings up more considerations than I anticipated around input/output differences. Since my use case would be supported by a successful land of #1616 anyway, I'll wait on this until after the PR is merged.

I appreciate your work on this library! It's definitely the best API generator I've used and I'm excited by the continuous improvements 🙂

[mrlubos]

Appreciate it! Much much more to come!

[sahandsn]

much needed.

[edward-meister]

any update in this issue?

[Stono]

Ah i was just about to raise an issue for this one, as when you turn on request validation which uses these zod schemas, it breaks any methods doing files.

Shamefully AI generated bug report:

# Bug: Zod generation ignores OpenAPI `format: binary` for request bodies

## Summary

When generating clients with `@hey-api/openapi-ts`, request-body schemas that use OpenAPI `type: string` plus `format: binary` are emitted correctly in `types.gen.ts` as `Blob | File`, but the corresponding Zod schemas in `zod.gen.ts` are generated as `z.string()`.

This makes the generated request validator reject valid binary upload inputs and effectively breaks request validation for file-upload endpoints.

## Package versions

- `@hey-api/openapi-ts`: `0.96.1`
- `zod`: `4`

## Minimal repro schema

```yaml
openapi: 3.0.0
info:
  title: Binary request repro
  version: 1.0.0
paths:
  /classify:
    post:
      operationId: classifyImage
      tags:
        - Classifier
      requestBody:
        required: true
        content:
          multipart/form-data:
            schema:
              type: object
              required:
                - image
              properties:
                image:
                  description: The image to classify
                  type: string
                  format: binary
      responses:
        '200':
          description: ok

Generator config

import { createClient } from '@hey-api/openapi-ts'

await createClient({
  input: schema,
  output: {
    path: './generated',
    clean: true
  },
  plugins: [
    'zod',
    {
      name: '@hey-api/sdk',
      validator: {
        request: true,
        response: false
      }
    }
  ]
})

Actual output

types.gen.ts contains the correct request-body type:

export type ClassifyImageData = {
  body: {
    image: Blob | File
  }
  url: '/classify'
}

But zod.gen.ts collapses the binary field to a string validator:

export const zClassifyImageBody = z.object({
  image: z.string()
})

That then flows into generated request validation:

requestValidator: async (data) =>
  await z.object({
    body: zClassifyImageBody
  }).parseAsync(data)

So passing a Blob or File fails validation even though the generated TypeScript type says it is valid.

Expected output

The Zod schema should preserve the binary intent instead of coercing to z.string().

Something equivalent to the following would be expected:

const zBinaryData = z.custom<Blob | File>(
  (value): value is Blob | File =>
    (typeof Blob !== 'undefined' && value instanceof Blob) ||
    (typeof File !== 'undefined' && value instanceof File),
  { message: 'Expected Blob or File' }
)

export const zClassifyImageBody = z.object({
  image: zBinaryData
})

Additional cases

The same issue also appears for direct binary bodies such as:

requestBody:
  required: false
  content:
    application/octet-stream:
      schema:
        type: string
        format: binary

In that case the generated request type is body?: Blob | File, while the generated Zod schema is still z.string().

Why this looks like an upstream bug

• The OpenAPI schema clearly marks the field as format: binary.
• The generated TypeScript model already interprets that correctly as Blob | File.
• The mismatch is specifically in the generated Zod output.
• When request validators are enabled, the generated SDK becomes internally inconsistent: the TypeScript type accepts binary input, while the validator rejects it.

Impact

• File upload endpoints cannot safely use generated request validation.
• Consumers either have to disable request validation or patch generated Zod schemas after generation.
• The bug is easy to miss because compilation succeeds and only runtime validation fails.

[Stono]

Ah just spotted #3627 which looks to be exactly the fix!