FHIR resources are serialized in multiple formats. Understanding when each applies avoids format confusion.
JSON (default)
Standard REST responses; individual resource GET/POST/PUT. Content-Type: application/fhir+json. Best for point-of-care, single-resource operations.
NDJSON
Bulk data streaming. Content-Type: application/fhir+ndjson. Each line is one resource. Best for Bulk Data `$export`, warehouse ingestion.
XML
Legacy option, application/fhir+xml. Best for HL7v2-to-FHIR converters that produce XML; declining use in 2026.
Turtle/RDF
FHIR RDF, text/turtle. Best for semantic web integrations, research federation. Niche.
Format selection by use case
| Use case | Format |
|---|---|
| Single resource CRUD | JSON |
| Bulk export | NDJSON |
| Legacy XML-only client | XML |
| Semantic integration | RDF/Turtle |
| Bundle transaction | JSON (usually) |
Serialization considerations
1. JSON canonical serialization. For digital signatures, use canonical JSON (RFC 8785). 2. NDJSON chunking. Large exports split into multiple files; each file valid NDJSON. 3. XML namespace handling. FHIR XML has specific namespaces; not casual XML. 4. UTF-8 mandatory. All formats require UTF-8.
Common format mistakes
1. NDJSON as JSON array — wrong format, parser fails. 2. JSON with wrong Content-Type — server may reject. 3. XML without namespaces — non-conformant. 4. Mixed formats in one Bundle — invalid.
Vendor format support (mid-2026)
| Server | JSON | NDJSON | XML | RDF |
|---|---|---|---|---|
| HAPI FHIR | Full | Full | Full | Partial |
| Aidbox | Full | Full | Full | External |
| Medplum | Full | Full | External | External |
| Microsoft FHIR Server | Full | Full | Full | External |
FHIR format handling is straightforward once the use case dictates the choice. JSON for CRUD, NDJSON for bulk, XML for legacy, RDF for semantic — done.