JSON to Rust Structs

What This Tool Does

This converter takes a JSON object and produces ready-to-compile Rust struct definitions decorated with #[derive(Serialize, Deserialize, Debug, Clone)]. Every JSON primitive maps to its closest Rust equivalent: "string" becomes String, integer numerics become i64 (or u64 when non-negative), floats become f64, booleans become bool, null becomes Option<T>, JSON arrays become Vec<T>, and nested objects become their own named structs linked from the parent struct field.

Field names follow Rust idiom — camelCase JSON keys are converted to snake_case Rust identifiers, with a #[serde(rename = "camelCase")] attribute added automatically so the wire format still matches the original JSON. Reserved Rust keywords like type, match, or ref are escaped to r#type, r#match, r#ref with the same serde rename safeguard. Three output modes are available: pure Serde derive, Serde derive plus Option wrapping on every field (defensive parsing for evolving APIs), and a Public Fields mode that adds pub visibility to every struct member.

The entire conversion runs in JavaScript inside your browser. No JSON sample, struct name, or generated code ever leaves the page — useful when the JSON contains internal API contracts, customer data, or anything else you would not want to paste into a remote service.

How to Use It

The interface is built for a single fast loop: paste, read, copy. The example below walks through every control on the page.

Paste Your JSON Sample

Drop a representative JSON object into the left input pane. The parser accepts any valid JSON — a single object, an array of objects (the first element drives type inference for the array), or even a primitive value (which generates a type alias). Whitespace is irrelevant; minified or pretty-printed both work. The textarea supports Tab for indentation rather than focus navigation, so you can fix formatting in place without leaving the field.

Pick a Generation Mode

The three option chips above the input control which derive style is emitted. Serde is the default — it produces minimal idiomatic structs suitable for stable, fully-populated API responses. Serde + Option wraps every field in Option<T>, a defensive posture useful when the upstream API is evolving or when you cannot guarantee every field is present on every response. Public Fields emits pub on every struct member, which is necessary when the structs need to be constructed by code outside the defining module.

Read the Generated Rust Code

The right pane updates live as you type (with a 150 ms debounce) and prints the generated Rust struct list with use serde::{Serialize, Deserialize}; at the top. Nested JSON objects produce sibling struct definitions named after their parent field in PascalCase — a JSON field profile: {...} becomes a Profile struct referenced from the parent. Arrays of objects produce structs suffixed with Item: tags: [{...}] generates a TagsItem struct.

Copy or Download Output

The Copy button puts the generated code on your clipboard for pasting straight into src/models.rs or wherever your DTO module lives. Download .rs saves the same text to a file named output.rs. The status bar below the panes reports how many structs and fields were generated, or — if your JSON failed to parse — exactly which token tripped the JSON parser, so syntax errors are easy to pinpoint.

Common Use Cases

JSON-to-Rust generation pays off most when you are crossing a boundary between Rust code and an external system that already speaks JSON. The following workflows are the ones the converter sees most heavily.

API Client Scaffolding

When you need to consume a third-party REST or GraphQL API from Rust — Stripe, GitHub, OpenAI, an internal microservice — paste a representative response from the API documentation or a curl probe directly into the converter. The generated struct becomes the response type for your reqwest::Client call. Add a corresponding request struct, derive Serialize on it, and the client is mostly written. For OpenAPI-described APIs the OpenAPI to Rust generator handles the same job at full-API scope, but for one-off endpoints the paste-a-sample workflow here is faster.

ETL Pipelines with serde_json

Batch ETL jobs that ingest JSON from S3, Kafka, or a vendor SFTP drop benefit from typed deserialization rather than walking serde_json::Value trees. Run a representative record through the converter, drop the struct into your job binary, and switch from let v: Value = serde_json::from_str(line)? to let rec: InvoiceLine = serde_json::from_str(line)?. The compiler then catches every field-access typo at build time rather than during the 3am pager call.

Config-File Schemas for clap / structopt

CLI tools written with clap or its earlier sibling structopt often accept a JSON or TOML config file. Defining the config schema as a serde-derived struct gives you free validation: missing required fields surface as deserialization errors before your CLI starts work, and the struct itself doubles as documentation for users writing their own config. The converter is a fast way to scaffold the config struct from a sample config.example.json committed to the repo.

Deserializing OpenTelemetry / Trace Data

Observability pipelines emit large volumes of structured JSON — OpenTelemetry spans, Sentry events, structured logs. A Rust-based collector or transformer that deserializes these payloads into typed structs runs faster and uses less memory than one that operates on Value trees, because it skips the dynamic dispatch overhead and benefits from compiler-driven layout optimization. Paste a sample span into the converter, refine the generated struct to use chrono::DateTime<Utc> for timestamp fields, and you have your collector's input type.

Axum and Actix-Web Request Handlers

Web framework handlers in Axum and Actix-Web accept request bodies through extractors that deserialize JSON into a struct — Json<T> in Axum, web::Json<T> in Actix. Paste a sample request body into the converter to generate the T. Add validation rules with the validator crate, derive Validate on the same struct, and the handler signature reads as a contract: deserialize, validate, then run business logic on a fully-typed value.

Edge Cases and Limitations

JSON's looseness and Rust's strictness collide in a handful of recurring patterns. Knowing them in advance saves a debugging round trip.

Heterogeneous arrays do not survive type inference. Rust's Vec<T> requires a single concrete T; an array like [1, "two", true, {"obj":1}] has no single Rust type. The converter detects this case and falls back to Vec<serde_json::Value> so the code still compiles. The idiomatic refactor is to define an enum with #[serde(untagged)] variants for each shape the array can contain, but enum inference from raw samples is not reliable, so the converter defers that decision to you.

Nullable fields need Option, not a sentinel value. A field that may be missing from the JSON entirely (key not present in the object) or that may carry a JSON null must be wrapped in Option<T>. Without Option, a missing key triggers a serde deserialization error and a null value triggers a type-mismatch error. The Serde + Option output mode wraps every field defensively; the default Serde mode only wraps fields that the converter saw as null in the sample.

Empty arrays force fallback typing. "tags": [] in your sample gives the converter no element to inspect, so it emits Vec<serde_json::Value> rather than guessing. Provide at least one representative element in the sample to get a concrete type. If you cannot, leave the fallback and refactor the type after generation when you have a real element to copy from.

snake_case rename attributes are not optional. Rust's standard library and major crate ecosystem all use snake_case for field and function names. The converter renames camelCase or PascalCase JSON keys to snake_case Rust identifiers and adds #[serde(rename = "originalKey")] so wire compatibility is preserved. If you delete the rename attribute, serialization will emit snake_case on the wire — breaking any consumer that expects the original casing. Either keep the rename or apply #[serde(rename_all = "camelCase")] at the struct level to handle every field uniformly.

Large integer values exceed i64. Integers larger than 9,223,372,036,854,775,807 (the i64::MAX) cannot deserialize into i64 without panicking. Common offenders are JavaScript-sourced timestamps in microseconds, Twitter snowflake IDs sent as raw numbers (rather than strings), and certain blockchain values. Three options: switch the field to u64 if you can guarantee non-negative, switch to the serde_with crate's DisplayFromStr helper to deserialize a numeric string into a large integer type, or refactor the upstream JSON producer to emit large integers as strings.

Date and timestamp parsing requires chrono. JSON has no native date type — dates arrive as ISO-8601 strings, Unix epoch numbers, or vendor-specific formats. The converter emits String for any string-shaped field by default; swap to chrono::DateTime<Utc> after generation when you confirm the format. For RFC 3339 ISO-8601, the chrono serde feature handles parsing automatically. For Unix epoch integers, use the serde_with::TimestampSeconds helper. For custom formats, write a tiny custom Deserialize impl using chrono::NaiveDateTime::parse_from_str.

Lifetimes for borrowed strings are rare in DTOs. Beginning Rust developers sometimes try to use &str in their generated structs for "performance." This only works when the deserialized buffer outlives the struct (the #[serde(borrow)] case), and adds a lifetime parameter to the struct that propagates through every consumer. For ordinary REST and ETL code, String is correct, ergonomic, and almost always fast enough — the allocation cost is dwarfed by network and disk I/O on the same code path.

Behind the Scenes: How Serde Generates Code

The Serde Framework (Tryzelaar, 2015)

Serde — the name is a portmanteau of "serialize" and "deserialize" — was created in 2015 by Erick Tryzelaar with significant contributions from David Tolnay, who remains its primary maintainer. Before Serde, Rust JSON handling went through rustc_serialize (a slow, runtime-reflective approach inherited from early Rust) or hand-written deserialization code. Serde's design pulled the ideas from Haskell's Aeson and Scala's Play JSON forward: define data structures once with derive macros, get serialization and deserialization for every format the ecosystem supports — JSON, YAML, TOML, MessagePack, CBOR, BSON, RON, Postcard — without writing per-format code.

Zero-Copy Where Possible

Serde is designed to deserialize without unnecessary allocations whenever the data model permits. A &str field with #[serde(borrow)] deserializes by pointing directly into the original input buffer rather than copying bytes into a fresh allocation. A Cow<str> field does the same when the input does not contain escape sequences, and falls back to an owned allocation only when escapes force a copy. For struct deserialization from JSON, Serde reads the input as a streaming token sequence — values are pulled into struct fields one at a time without ever materializing the full Value tree in memory. This is what makes Serde-based ETL pipelines fast: they pay the parse cost once, in a streaming fashion, with no intermediate dynamic representation.

#[derive] Macro Expansion

When you write #[derive(Serialize, Deserialize)], Rust's procedural-macro system invokes Serde's derive crate at compile time. The macro receives your struct's syntax tree and synthesizes two trait implementations: one for Serialize (a method that walks the struct's fields and emits them through a Serializer), and one for Deserialize (a Visitor-pattern implementation that consumes input tokens and reconstructs the struct). The generated code is monomorphic — there is no runtime reflection, no virtual dispatch — which is why Serde matches or beats hand-written deserialization in benchmarks. You can inspect the generated code with cargo expand if you are curious; the output is large but human-readable.

Alternative Codecs in the Serde Ecosystem

Once a struct derives Serde traits, it can be encoded in any format with a Serde codec. JSON via serde_json is the default, but the same struct works with Postcard for compact embedded systems messaging (no dependencies on std, designed for microcontrollers), MessagePack via rmp-serde for binary efficiency, CBOR via ciborium for IoT use, TOML via toml-rs for config files, and YAML via serde_yaml. The same struct definition serves as the schema across all of them — generate from JSON here and re-use the struct against MessagePack in production for wire savings.

Comparison: This Tool vs Alternatives

Several other tools and crates exist for generating Rust code from JSON or schema descriptions. Each has a different scope and a different trade-off profile.

quicktype.io is the most prominent web-based JSON-to-code generator, supporting Rust as one of dozens of target languages. Its strengths are multi-language coverage and a rich set of formatting options. Its trade-offs versus the in-browser tool here: quicktype runs in a remote service unless you self-host it, the Rust output sometimes uses Option more aggressively than necessary, and the tool is geared toward general code generation rather than the specific Serde-idiomatic patterns that production Rust APIs use. For one-off snippets and quick scaffolding, the ThisDevTool converter is more direct.

schemafy_lib is a Rust crate that generates structs from JSON Schema documents (not raw JSON samples). If your upstream data source publishes a JSON Schema — many enterprise APIs and OpenAPI-described services do — schemafy lets you regenerate types from schema during your build.rs script, keeping the Rust types in sync with the published schema automatically. The downside is that JSON Schema is a separate document type that not every API provides, and writing one by hand from a raw JSON sample is more work than the paste-into-this-tool path.

typify is a newer Rust crate from the Oxide Computer team that generates Rust types from JSON Schema with significantly better handling of advanced schema features (oneOf, anyOf, allOf compositions, recursive references) than schemafy provides. Typify is the right answer when your project already has a comprehensive JSON Schema and you want the type generation tightly coupled to the schema version. It is overkill when you are working from a raw JSON sample and just need a struct.

The ThisDevTool converter sits at the lightest weight point on this spectrum: paste a sample, copy the result. No build script, no schema file, no remote service. For the common case of "I have a JSON payload, I want a struct," it gets you to a compiling Rust file in well under a minute, and the result is idiomatic enough to ship after minor edits.