JSON to Rust Struct — serde Derives, snake_case, Option, Zero Upload

Real-world use cases

• Type a third-party API response without hand-writing structs

  You're integrating the GitHub API from Rust and the user object has 30+ fields. Curl the endpoint once, paste the JSON here, set the root name to `GitHubUser`, copy the output into `src/github.rs`. The nested `plan` object lifts out as `GitHubUserPlan` automatically, `html_url` keeps its snake_case form, and `serde_json::from_str` fills a fully-typed struct instead of a `serde_json::Value` you have to index with brittle `["plan"]["seats"]` chains.

• Map a camelCase API onto idiomatic Rust fields

  A JS-fronted backend sends `{ "userId": 7, "isActive": true, "createdAt": "..." }`. Paste it and the fields become `user_id`, `is_active`, `created_at`, each with a `#[serde(rename = "userId")]` attribute. You get clean snake_case Rust that reads naturally and a serde layer that still speaks the API's camelCase on the wire — no manual rename annotations, no clippy `non_snake_case` warnings.

• Decide Option vs required for a flaky webhook payload

  A vendor's webhook sometimes includes `cancelled_at` and sometimes omits it. Log the first few payloads, paste them as a JSON array, and the optional-field detection wraps `cancelled_at` in `Option<String>`. Now `match event.cancelled_at { Some(ts) => ..., None => ... }` cleanly distinguishes "cancelled" from "still active" instead of panicking on a missing key at deserialize time.

• Replace a serde_json::Value blob with a real type

  Old code does `let data: serde_json::Value = serde_json::from_str(s)?` then reaches in with `data["user"]["id"].as_i64()` and `.unwrap()`s everywhere. Capture one representative response, paste it, generate the struct, deserialize into it directly. The `.as_i64().unwrap()` chains that panic in prod disappear — `i64` and `f64` are inferred at the field level and the compiler checks every access.

• Generate config types for a Rust service

  Your service reads a `config.json`. Paste it, name the root `Config`, turn on `#[serde(default)]` so a partial config file still deserializes, and get `Config`, `ConfigServer`, `ConfigServerTls` nested structs with `i64` ports and `bool` flags. Drop them in `config.rs`, call `serde_json::from_reader(file)?`, and your config is type-checked at compile time instead of failing at runtime on a typo'd key.

Common pitfalls

• Pasting a single object and expecting some fields to be Option. A single object has no missing-key signal, so every field is required. Option inference only kicks in across an array of objects where some elements carry a key and others don't, or where a value is null. To explore optionality from one sample, wrap it as `[{...}]`.

• Expecting u64 / i32 for IDs. JSON gives no sign or width, so every integer infers as i64 — the safe superset. A negative value would break u64, and i32 would overflow on ms timestamps or snowflake IDs. Narrow the type by hand only when you know the real domain; the default always compiles and always deserializes.

• Treating a field that's only ever null as a typed field. `{"meta": null}` gives `Option<serde_json::Value>` because null carries no type information. If you know the real shape, feed a non-null sample (`{"meta": {"k": 1}}`) so the tool can infer a proper struct.

• Forgetting the serde derive feature. The output uses `#[derive(Serialize, Deserialize)]`, which needs `serde = { version = "1", features = ["derive"] }` in Cargo.toml. Without the `derive` feature the code won't compile — and `serde_json` is required whenever the output contains `serde_json::Value` or a `HashMap` catch-all.

• Pasting JSON5 / JSON-with-comments / trailing commas. We use strict `JSON.parse`, so comments, unquoted keys, and trailing commas all error out. Strip them first, or pipe through a JSON formatter as a pre-step.

Privacy