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 FormatWhen To Use It
TypeScriptDefining API response types in your frontend
Go StructsParsing JSON in Go microservices
Java ClassesJackson/Gson deserialization in Spring Boot
Python dictsTypedDict or dataclass definitions
C# ClassesNewtonsoft.Json or System.Text.Json models
YAMLConfig files, Kubernetes manifests, CI pipelines
XMLLegacy system integration, SOAP APIs
CSVData 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 boolean true in YAML unless quoted
  • Number formatting: Zip codes like "00501" become integer 501 in YAML
  • Multi-line strings: JSON \n escape 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:

  1. Flatten with dot notation: user.name, user.address.city
  2. 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": []
}
  • 0 as a value: Some languages treat 0 as falsy. Go and Python handle it fine, but in JavaScript comparisons, if (data.count) fails even when 0 is a valid value.
  • "false" as a string: YAML converts this to boolean false if you're not careful.
  • Empty arrays []: Go unmarshals these to nil slices by default, which breaks len() calls. Use make([]Type, 0) initialization instead.
  • Null handling: Every language handles null differently. None in Python, nil in Go, null in Java, null in 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.