JSON to Ecto Schema Generator

Generate Elixir Ecto schema definitions with changeset functions from JSON data.

What is JSON to Ecto Schema Generator?

Ecto is Elixir's primary database wrapper and query generator, and schemas are the bridge between your Elixir code and PostgreSQL tables. An Ecto schema defines the table name, field names and types, and optionally a `changeset/2` function that casts, validates, and transforms incoming data before it reaches the database. This generator inspects your JSON sample, infers the correct Ecto field type for each value (`:string`, `:integer`, `:float`, `:boolean`), and produces complete `defmodule` definitions with `use Ecto.Schema` and `import Ecto.Changeset`. Nested JSON objects become either `embeds_one` definitions (stored as JSONB in the same table) or `has_one` associations (separate table with foreign key), depending on your selection. Arrays of objects generate `has_many` associations. The optional changeset function includes `cast`, `cast_embed`/`cast_assoc`, and `validate_required` for all non-null fields, following the standard Phoenix pattern.

How to Use

  1. Set the Elixir module prefix (e.g. MyApp.) — this is prepended to every schema module name following Elixir naming conventions
  2. Configure schema options: embeds_one vs has_one for nested objects, whether to include changeset functions and timestamps
  3. Paste a representative JSON response from your API into the input area and click "Generate"
  4. Copy the generated schema modules into your Phoenix project — each nested object becomes its own module in a separate .ex file or a single file
  5. Run mix ecto.migrate after adding the generated schemas to create the corresponding database tables

Why Use This Tool?

Infers Ecto atom types from JSON values — :string, :integer, :float, :boolean — matching the exact type names used in Ecto schema field definitions
Generates complete defmodule definitions with use Ecto.Schema and import Ecto.Changeset, ready to paste into your Phoenix project without modification
Nested objects become embeds_one (JSONB in same table) or has_one (separate table with foreign key) based on your selection — embeds for value objects, associations for entities with their own lifecycle
The changeset function follows the standard Phoenix pattern: cast for field filtering, cast_embed/cast_assoc for nested data, and validate_required for non-null fields
Arrays of objects automatically generate has_many associations with the correct module reference and cast_assoc in the changeset
Optional timestamps() adds inserted_at and updated_at columns that Phoenix auto-populates

Tips & Best Practices

  • Use embeds_one for value objects that belong exclusively to the parent and never need independent querying — addresses, settings, and metadata are good candidates
  • Use has_one for entities with their own lifecycle that might be queried independently — a user profile that can exist before the user confirms their email
  • The changeset function uses the schema name as the first argument variable (e.g. root instead of struct) — rename it to something meaningful like user or product after generation
  • Ecto arrays map to {:array, :type} which PostgreSQL stores natively — use this for simple lists like tags. For complex nested arrays, prefer has_many associations instead
  • Embedded schemas (embedded_schema do) do not need a table name or primary key — they are stored as JSONB columns in the parent table and are ideal for configuration or settings data

Frequently Asked Questions

How does this tool map JSON types to Ecto schema field types?

JSON strings become :string, integers become :integer, floating-point numbers become :float, and booleans become :boolean. Null values generate optional fields without validate_required constraints. Arrays of primitives produce {:array, :type} tuples like {:array, :string}, while arrays of objects become has_many associations referencing separate schema modules. Nested objects become embeds_one or has_one depending on the nesting mode you select — embeds for value objects stored as JSONB, associations for entities with their own database tables.

When should I NOT use this Ecto schema generator?

Avoid this generator when your JSON represents a flat key-value config with no meaningful nesting — a simple map or keyword list in Elixir would be more appropriate. Also skip it when you need to generate migration files alongside schemas, since this tool only produces the schema and changeset code. If your data model requires complex polymorphic associations, composite primary keys, or many-to-many join tables, you will need to manually extend the generated output because those patterns cannot be inferred from a single JSON sample.

Is my JSON data sent to any external server?

No. All conversion runs entirely in your browser using client-side JavaScript. Your JSON payload is never transmitted to any server, logged, or stored. You can verify this by disconnecting your network — the tool will still work. This makes it safe for pasting API responses, database records, or any sensitive data structures.

What is the difference between schema and embedded_schema in the generated output?

A regular schema (schema "table_name" do) maps to a dedicated database table with a primary key and timestamps. An embedded_schema does not have a table — it serializes as a JSONB column inside the parent record. Use embedded_schema for value objects like addresses or preferences that never need to be queried independently. The generator uses embedded schemas for embeds_one fields and regular schemas for top-level and has_many/has_one associations.

Why does the changeset use cast_embed instead of cast_assoc for nested objects?

When you select the embeds nesting mode, nested objects become embedded schemas stored in the same table, so the changeset calls cast_embed to validate and cast them. If you select the association mode, nested objects become separate tables linked by foreign keys, and the changeset uses cast_assoc instead. The two functions behave differently: cast_embed expects the embedded data inline, while cast_assoc can accept changeset data or existing records. Mixing them up is a common source of Ecto errors.

Can I use the generated schema with Phoenix contexts and LiveView?

Yes. The generated defmodule and changeset/2 function follow the standard Phoenix conventions that contexts expect. You can paste the schema into your context module directory, run mix ecto.migrate after creating the corresponding migration, and immediately use it in LiveView with Phoenix.Component.assigns or in controllers with Repo.insert/insert_all. The changeset pattern also works seamlessly with Phoenix form bindings — just pass the changeset to your form component as you would with any hand-written schema.

Real-world Examples

Phoenix API with nested product catalog

A team building a marketplace API receives product data from a supplier feed as JSON with nested categories and variant arrays. They paste the feed into this tool, select embeds mode for the category object (since it is a value object), and get a complete Ecto schema with embeds_one for the category and has_many for the variants. After adding a migration with mix ecto.gen.migration, the schema is ready for their Products context — the changeset validates required fields and casts the embedded category automatically.

SaaS onboarding with user settings

A SaaS platform stores per-user preferences as a JSONB column in the users table. The product team defines a settings schema from a sample JSON payload, and the generator produces an embedded_schema that maps directly to the JSONB column. This avoids creating a separate settings table while still providing type-safe changesets and validation. The frontend sends PATCH requests with partial updates, and the changeset applies only the cast fields.

Related Tools