Are the generated objects exact or inexact?

Neither is written down: the output uses plain `{ … }`, so your `.flowconfig` decides. With `exact_by_default=true` — the setting recent Flow versions ship — those objects are exact. Without it they are inexact. Adding `{| |}` or a trailing `...` would override a project-wide choice the sample knows nothing about.

Why `mixed` and not `any`?

Because `mixed` is the honest one. An empty array tells you nothing about its items, and `mixed` says exactly that while still forcing you to refine before use. `any` would say the same thing and then let every mistake through silently — an unknown type is not a reason to switch the checker off.

Should I still start a project in Flow?

That is your call, and this tool works either way. Flow is alive and used, mostly in codebases that predate TypeScript\u2019s rise or live inside Meta\u2019s ecosystem. If you are choosing today with no such constraint, TypeScript has the larger library of type definitions — and this site converts to it too.

JSON to Flow — Type Aliases for Your Project

Turn a JSON sample into Flow type aliases. Nested objects get their own names, so a payload becomes types you can import where you need them.

Instant Private Zero cookies

Root name

JSON input

Flow output

What this tool does

A JSON sample becomes Flow type aliases, one per object.

{ "id": 1, "name": "Ada", "address": { "city": "Paris" } }

export type Root = {
  id: number,
  name: string,
  address: Address,
};

export type Address = {
  city: string,
};

A list at the root is named too:

export type Users = UsersItem[];

That alias used to be missing — the item type came out alone, and the root name you had set went nowhere. It was found while writing this page and fixed.

Exactness is not ours to decide

The output writes { … }, neither {| … |} nor a trailing .... Under exact_by_default=true, which recent Flow versions enable, that object is exact: an extra property is an error. Without the flag it is inexact and extra properties are allowed.

Both are defensible, and the difference is a project-wide decision recorded in your .flowconfig. Writing the sigil either way would override that decision on the basis of a sample that says nothing about it, so the generated type simply follows your configuration.

`mixed`, not `any`

An empty array gives mixed[]; a value of unknown shape gives mixed. The point of mixed is that Flow makes you narrow it before use, which is what you want when the type really is unknown. any would look tidier in the output and disable the checker exactly where the data is least understood.

What one document cannot say

Nothing is optional: name: string means present, because the sample had it. If the field is sometimes absent, name?: string is the edit to make, and string | null if it can be null — the sample only proves what it contains.

A mixed array becomes a union type, (number | string)[], which describes the sample precisely and may be wider or narrower than your real data. And a key that is not a valid identifier keeps its quotes: "content-type": string.

Private by design

Everything runs locally in your browser with JavaScript. Your data is never uploaded, which makes the tool safe for sensitive content, and it keeps working offline.

Frequently asked questions

Are the generated objects exact or inexact?: Neither is written down: the output uses plain `{ … }`, so your `.flowconfig` decides. With `exact_by_default=true` — the setting recent Flow versions ship — those objects are exact. Without it they are inexact. Adding `{| |}` or a trailing `...` would override a project-wide choice the sample knows nothing about.
Why `mixed` and not `any`?: Because `mixed` is the honest one. An empty array tells you nothing about its items, and `mixed` says exactly that while still forcing you to refine before use. `any` would say the same thing and then let every mistake through silently — an unknown type is not a reason to switch the checker off.
Should I still start a project in Flow?: That is your call, and this tool works either way. Flow is alive and used, mostly in codebases that predate TypeScript\u2019s rise or live inside Meta\u2019s ecosystem. If you are choosing today with no such constraint, TypeScript has the larger library of type definitions — and this site converts to it too.