JSON to Rust Struct Generator

Example Input

{
  "id": 1,
  "userName": "priya_singh",
  "email": "priya@learnhubly.com",
  "isActive": true,
  "score": 98.5,
  "tags": ["developer", "admin"],
  "profile": {
    "bio": "Principal Software Engineer",
    "skills": ["Go", "Rust", "TypeScript"]
  },
  "deletedAt": null
}

Example Output

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
pub struct Profile {
    pub bio: String,
    pub skills: Vec,
}

#[derive(Debug, Serialize, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct User {
    pub id: i64,
    pub user_name: String,
    pub email: String,
    pub is_active: bool,
    pub score: f64,
    pub tags: Vec,
    pub profile: Profile,
    pub deleted_at: Option,
}

// Cargo.toml dependencies:
// serde = { version = "1", features = ["derive"] }
// serde_json = "1"

// Usage:
// let user: User = serde_json::from_str(json_str)?;
// let json: String = serde_json::to_string(&user)?;

Does it handle Option types?

Yes. Any JSON field that appears as null in the sample generates Option in the Rust struct, where T is inferred from context. A null string field becomes Option, a null integer becomes Option. serde deserializes a JSON null value as None and a present value as Some(value). Fields that are completely absent from the JSON behave differently from null — see the serde(default) discussion in Common Mistakes for the distinction. After generating, review each Option field and decide whether it genuinely needs to be optional or whether you know it will always be present — non-optional fields produce cleaner downstream code.

How do I add the serde dependency to my project?

Add these two lines under [dependencies] in your Cargo.toml: serde = { version = '1', features = ['derive'] } and serde_json = '1'. The features = ['derive'] is mandatory — without it, the derive macros (#[derive(Serialize, Deserialize)]) are not compiled and the generated code will not compile. If you are using async Rust with Tokio, you likely already have serde in your dependency tree through other crates like axum or reqwest — check Cargo.lock first to avoid version conflicts, though serde 1.x is backward compatible so duplicates are not usually a problem.

What is the difference between serde_json::from_str and serde_json::from_value?

serde_json::from_str(json_string) deserializes a raw JSON string (&str or String) directly into a typed Rust struct — this is the most efficient approach when you receive JSON as text (from an HTTP response body, a file, a message queue). serde_json::from_value(json_value) deserializes a serde_json::Value (the weakly-typed JSON representation) into a struct — use this when you have already parsed the JSON into a Value for inspection or manipulation and want to convert a portion of it into a typed struct. For HTTP responses with reqwest, the typical pattern is: let response: MyStruct = reqwest::get(url).await?.json::().await? which handles the deserialization internally.

Is it safe to use this with internal or proprietary API response data?

Yes. Everything runs in your browser. The JSON you paste is processed by JavaScript locally and never transmitted to any server. This matters for API responses that contain authentication tokens, internal endpoint paths, customer data, or any other information you would not want a third-party service to process. The generated Rust code is just text — copy it, close the tab, and the data is gone.

How do I handle JSON fields whose type can be multiple different types?

Some APIs return fields that can be either a string or an integer, or either a specific object or null with a different null representation than serde expects. For these cases, the generated String or i64 type will not work universally. The options are: use serde_json::Value as the field type (completely flexible but requires runtime type checking), write a custom deserializer with #[serde(deserialize_with = 'my_fn')] that handles the type ambiguity, or use an untagged enum: #[serde(untagged)] enum StringOrInt { String(String), Int(i64) }. The untagged enum approach is the most idiomatic Rust solution — it preserves type safety while handling multiple possible representations.

How do I use the generated struct with reqwest for HTTP requests?

With reqwest (the dominant Rust HTTP client): for deserializing a response body into a struct, use let response: MyStruct = client.get(url).send().await?.json::().await?. The .json() method handles the deserialization using serde_json. For sending a struct as a JSON request body, use .json(&my_struct) on the request builder: client.post(url).json(&my_struct).send().await?. This serializes the struct to JSON using serde_json::to_string() internally. Both directions require the struct to implement Deserialize (for receiving) and Serialize (for sending) — the generated #[derive(Serialize, Deserialize)] handles both.

Can I add validation to the generated struct fields?

serde itself does not provide field-level validation beyond type checking. For input validation on deserialized data, the most popular approach in the Rust ecosystem is the validator crate: add #[derive(Validate)] to the struct and add #[validate(...)] attributes to fields (validate(email), validate(length(min = 1, max = 255)), validate(range(min = 0, max = 100))). Call data.validate()? after deserialization. Actix-web has a Json extractor variant that runs validation automatically. Another approach is newtype wrappers — instead of pub email: String, define a newtype Email(String) that validates the format in its TryFrom implementation, then use pub email: Email in the struct. The newtype approach makes invalid states unrepresentable at the type level.

What should I know about serde performance for high-throughput services?

serde_json is fast — benchmarks consistently put it among the fastest JSON parsers in any language, competitive with simdjson. The derive macros generate code at compile time with no runtime reflection overhead. For most applications, serde_json performance is not a bottleneck. If you are processing very high message volumes (millions of messages per second), consider: using simd_json (a SIMD-accelerated JSON parser with serde compatibility) as a drop-in replacement for serde_json, using serde_json::from_slice instead of from_str to avoid an extra UTF-8 validation step, and minimizing allocations by reusing buffers. For Kafka consumers and other streaming scenarios, the bottleneck is almost always I/O and network, not JSON deserialization.