Last week, a teammate came to me with a problem. "The backend team sent me this massive JSON schema, and I need to turn it into TypeScript interfaces for our frontend. Do I have to type all of that by hand?"
I laughed — not because it was a dumb question, but because I'd asked the exact same thing two years ago. I spent three hours manually crafting interfaces from a 500-line JSON response. Three hours. For something that should take three seconds.
That's the moment I realized: JSON conversion is one of those tasks that developers do constantly but rarely optimize. We manually translate, copy-paste, regex-replace — when there are tools that do it perfectly in one click.
Why Convert JSON At All?
JSON is great for data interchange, but it's rarely the final format you work with. Here's when each conversion makes sense:
| Target Format | When To Use It |
|---|---|
| TypeScript | Defining API response types in your frontend |
| Go Structs | Parsing JSON in Go microservices |
| Java Classes | Jackson/Gson deserialization in Spring Boot |
| Python dicts | TypedDict or dataclass definitions |
| C# Classes | Newtonsoft.Json or System.Text.Json models |
| YAML | Config files, Kubernetes manifests, CI pipelines |
| XML | Legacy system integration, SOAP APIs |
| CSV | Data export, spreadsheet analysis, reporting |
Let's walk through each one with real examples.
JSON to TypeScript
This is the most common conversion I do daily. Given this API response:
{
"user": {
"id": "u_88421",
"name": "Alice Chen",
"email": "alice@example.com",
"roles": ["admin", "editor"],
"profile": {
"avatar_url": null,
"bio": "Full-stack developer",
"social_links": {
"github": "https://github.com/alice",
"twitter": null
}
}
}
}
A good converter produces:
interface SocialLinks {
github: string;
twitter: string | null;
}
interface Profile {
avatar_url: string | null;
bio: string;
social_links: SocialLinks;
}
interface User {
id: string;
name: string;
email: string;
roles: string[];
profile: Profile;
}
Notice how it handles null fields correctly (string | null), nests interfaces, and infers array types. The best converters also let you toggle between interface and type aliases.
JSON to Go Structs
Go's strict typing makes JSON parsing either beautiful or painful, depending on how you set up your structs.
{
"service": "auth-api",
"version": "2.4.1",
"endpoints": [
{
"path": "/login",
"method": "POST",
"rate_limit": 100,
"timeout_ms": 3000
}
],
"enabled": true
}
The generated Go struct should look like:
type Endpoint struct {
Path string `json:"path"`
Method string `json:"method"`
RateLimit int `json:"rate_limit"`
TimeoutMs int `json:"timeout_ms"`
}
type ServiceConfig struct {
Service string `json:"service"`
Version string `json:"version"`
Endpoints []Endpoint `json:"endpoints"`
Enabled bool `json:"enabled"`
}
The json: tags are the critical part — without them, Go's default serialization uses the field name as-is, which doesn't match snake_case JSON keys. A good converter adds these automatically.
JSON to Java Classes
For Spring Boot projects using Jackson:
{
"order_id": "ORD-77291",
"customer": {
"first_name": "Bob",
"last_name": "Smith"
},
"items": [
{
"product_id": "PROD-33",
"quantity": 2,
"unit_price": 24.99
}
],
"total": 49.98
}
Generated Java:
import com.fasterxml.jackson.annotation.JsonProperty;
public class Item {
@JsonProperty("product_id")
private String productId;
@JsonProperty("quantity")
private int quantity;
@JsonProperty("unit_price")
private double unitPrice;
}
public class Customer {
@JsonProperty("first_name")
private String firstName;
@JsonProperty("last_name")
private String lastName;
}
public class Order {
@JsonProperty("order_id")
private String orderId;
@JsonProperty("customer")
private Customer customer;
@JsonProperty("items")
private List<Item> items;
@JsonProperty("total")
private double total;
}
The @JsonProperty annotations handle the snake_case-to-camelCase mapping. Without them, Jackson would expect fields named order_id in your Java class too — which violates Java naming conventions.
JSON to Python (TypedDict)
Python developers have two main options: TypedDict for type hints or dataclass for more functionality.
from typing import List, Optional, TypedDict
class Item(TypedDict):
product_id: str
quantity: int
unit_price: float
class Customer(TypedDict):
first_name: str
last_name: str
class Order(TypedDict):
order_id: str
customer: Customer
items: List[Item]
total: float
If you're using Pydantic (FastAPI projects), the converter should also offer a Pydantic BaseModel variant with validators.
JSON to C# Classes
For .NET developers working with System.Text.Json or Newtonsoft.Json, I've written a detailed guide separately — check out JSON to C#: Generate Strongly Typed Classes from Any JSON Response for the full walkthrough.
JSON to YAML
YAML is where JSON goes when it wants to be human-readable. The conversion is mostly straightforward:
api_version: "v2"
services:
auth:
port: 8080
replicas: 3
env:
- name: NODE_ENV
value: production
health_check:
endpoint: /health
interval_secs: 30
payment:
port: 8081
replicas: 5
env:
- name: STRIPE_KEY
value_from:
secret_key_ref: stripe-prod-key
Watch out for edge cases:
- Boolean-like strings:
"yes"and"true"in JSON become booleantruein YAML unless quoted - Number formatting: Zip codes like
"00501"become integer501in YAML - Multi-line strings: JSON
\nescape sequences should become YAML block scalars (|or>)
A good converter handles these automatically. Our tool at /json-formatter.html does, and it also preserves comments if your JSON has them.
JSON to XML
This conversion feels increasingly rare in greenfield projects, but when you're integrating with a legacy SOAP service, it's unavoidable.
{
"invoice": {
"number": "INV-2026-0042",
"date": "2026-06-01",
"line_items": [
{
"sku": "SVC-HOSTING",
"description": "Web hosting monthly",
"amount": 29.99
}
]
}
}
Becomes:
<?xml version="1.0" encoding="UTF-8"?>
<root>
<invoice>
<number>INV-2026-0042</number>
<date>2026-06-01</date>
<line_items>
<item>
<sku>SVC-HOSTING</sku>
<description>Web hosting monthly</description>
<amount>29.99</amount>
</item>
</line_items>
</invoice>
</root>
The tricky part is array handling. JSON arrays have no named elements, so converters need to decide on a wrapping element name (usually item or the parent key in singular form). A good converter lets you customize this.
JSON to CSV
CSV is the simplest format here but the most restrictive. CSV is flat — you can't have nested objects.
[
{"name": "Alice", "age": 30, "city": "New York"},
{"name": "Bob", "age": 25, "city": "San Francisco"}
]
Becomes:
name,age,city
Alice,30,New York
Bob,25,San Francisco
For nested JSON, you have two strategies:
- Flatten with dot notation:
user.name,user.address.city - JSON-stringify nested values: Put the nested object as a string in one cell
Most converters offer both options. If you're sending data to a business analyst, option 1 is better. If you need to preserve the structure for re-import, option 2 works.
Common Conversion Pitfalls
I've been bitten by each of these at least once:
{
"count": 0,
"name": "false",
"items": []
}
0as a value: Some languages treat0as falsy. Go and Python handle it fine, but in JavaScript comparisons,if (data.count)fails even when0is a valid value."false"as a string: YAML converts this to booleanfalseif you're not careful.- Empty arrays
[]: Go unmarshals these tonilslices by default, which breakslen()calls. Usemake([]Type, 0)initialization instead. - Null handling: Every language handles
nulldifferently.Nonein Python,nilin Go,nullin Java,nullin C# — make sure your converter respects the language's convention.
When to Convert and When to Keep JSON
Not every JSON needs converting. JSON is still the best format for:
- API request/response bodies
- Configuration that's consumed programmatically
- Data sent over the wire (compact, fast to parse)
- NoSQL database documents
Convert to other formats when:
- You need type safety at compile time (TypeScript, Go, Java, C#)
- You need human readability (YAML)
- You need legacy compatibility (XML)
- You need tabular analysis (CSV)
FAQ
Q: Can I convert JSON to TypeScript with optional ? markers?
A: Yes, many converters offer a "strict" mode toggle. If a field has null in some samples, it becomes optional (field?: type). Without the toggle, it becomes field: type | null.
Q: How do I handle circular references during JSON conversion?
A: Circular references can't be directly serialized. You'll need to break the cycle — either by using references (JSON Schema $ref) or by restructuring the data. Most converters will error or truncate at the circular point.
Q: Does JSON to XML conversion handle attributes vs elements?
A: Basic converters put everything as elements. Advanced converters let you mark specific keys as XML attributes with a prefix like @ (e.g., @id).
Q: What happens when JSON arrays have mixed types?
A: In TypeScript, it becomes a union type (string | number)[]. In Go, it's trickier — you'd use []interface{} or a custom unmarshaller. C# uses List<object>. Always try to make arrays uniform in your JSON if possible.
Q: Can I batch-convert multiple JSON files at once?
A: Most online tools handle one file at a time. For batch conversion, you'd write a script using jq or a language-specific library. But for everyday use, one-at-a-time with instant preview is faster than scripting.
Q: How does the converter know whether to use interface or type in TypeScript?
A: Most converters default to interface because they're extendable and give better error messages. Some offer a toggle. If you're working with union types or computed properties, switch to type.
Q: Does JSON to CSV preserve my column order?
A: Most converters sort alphabetically by default. Look for a "preserve order" option. If you're doing repeated exports, a consistent column order is critical for downstream automation.
Q: Can I convert CSV back to JSON?
A: Yes, but it's lossy — nested structures can't be recovered from a flat CSV. You'll get flat JSON objects with dot-notation keys or stringified values, depending on the tool.
Try It Yourself
Instead of manually typing out interfaces or structs next time, use a proper conversion tool. It takes seconds instead of hours, and it eliminates the copy-paste typos that waste even more time debugging.
Fire up the JSON Formatter, paste your JSON, and see how fast you can go from raw data to production-ready code.