OCPP 1.6 JSON vs SOAP - Why JSON Won
Why OCPP 1.6J (JSON over WebSocket) dominates deployments, where SOAP still shows up, and what to do if you inherit a SOAP fleet.
OCPP 1.6 JSON vs SOAP. Why JSON Won
OCPP 1.6 ships in two variants: 1.6J (JSON over WebSocket) and 1.6S (SOAP over HTTP). If you're starting anything new in 2026, you'll use JSON. But SOAP hasn't completely disappeared from the field, and if you're inheriting an older deployment, you need to know why the difference matters.
Side by side
| OCPP 1.6J (JSON) | OCPP 1.6S (SOAP) | |
|---|---|---|
| Transport | WebSocket | HTTP |
| Data format | JSON | XML |
| Connection | Persistent, bidirectional | Request-response |
| Server → Charger | Native via WebSocket | Charger must expose HTTP endpoint |
| Message overhead | ~100-200 bytes | ~2-5 KB (XML envelope + namespaces) |
| Tooling | Parse with JSON.parse() | Need XML parsing, WSDL generation |
| Modern support | Universal | Declining |
Why JSON dominates
WebSocket is bidirectional. With SOAP over HTTP, the backend can't push messages to the charger without the charger exposing an inbound HTTP endpoint. That means the charger needs a public IP or port forwarding. NAT traversal becomes a headache, firewalls block inbound connections.
With JSON/WebSocket, the charger opens one outbound connection and both sides talk freely. No firewall issues.
Rendering diagram...
Messages are small. A typical StartTransaction in JSON is about 140 bytes. The same message in SOAP, with XML namespaces and envelope, is 2-3 KB. On constrained hardware with a slow cellular link, that difference adds up.
Developer experience. JSON is native to every language used in modern backends. JSON.parse() and you're done. SOAP requires XML parsing, WSDL generation, namespace handling, and usually a specialised library. It's not impossible, just friction nobody wants.
Where SOAP still shows up
Legacy chargers. Many units manufactured before 2018-2019 only support OCPP 1.6S. If an operator has hundreds in the field, they're not replacing them for a protocol variant.
Government and utility networks. Some older procurement specs required SOAP explicitly. XML-based protocols were considered "enterprise-grade" at the time.
Specific regions. Pockets of SOAP-only deployments exist in parts of Europe, Asia, and South America from early EV infrastructure programs.
Migrating from SOAP to JSON
If you're stuck with SOAP and want to move:
Rendering diagram...
Many chargers actually support both variants but were configured for SOAP at deployment because that's what the original CSMS required. Often a firmware update adds JSON support, or it's already there. you just change the endpoint URL.
Run both protocols in parallel during migration. Your backend can accept both. Switch chargers one by one, test, then move to the next batch.
OCPP 2.0.1 is JSON only
There's no SOAP variant in OCPP 2.0.1. If your roadmap includes upgrading to 2.0.1 eventually, JSON support is mandatory anyway.
Rendering diagram...
The direction is clear. JSON won. Plan accordingly.