In technical documents from the OCPP 1.5 and 1.6 era you will often see the terms "OCPP-J" and "OCPP-S". They are two different transport methods for the same protocol. Which one is used directly affects the charger's network settings, firewall rules and which software it can work with.

What is OCPP-S?

The "S" in OCPP-S stands for SOAP. Messages are encoded in XML and carried in HTTP requests. The first OCPP versions (1.2 and 1.5) used SOAP only. In this model both sides act as web services: the charger sends requests to the central system, and the central system reaches the charger with its own separate HTTP requests.

The core problem is that, for the central system to send requests to the charger, the charger needs an address that is reachable from the internet. For a charger on a mobile connection or behind NAT this is often impossible without extra measures such as port forwarding or a VPN.

What is OCPP-J?

The "J" in OCPP-J stands for JSON. Messages are encoded as lightweight JSON arrays and carried over a single persistent WebSocket connection. The charger always opens the connection. Once it is open, both sides can send messages over the same channel whenever they need to.

The consequences of this approach:

  • The charger needs no static IP address or port forwarding; it even works behind a 4G modem.
  • Messages are much smaller than XML, so mobile data usage drops.
  • The central system can deliver commands such as remote start or reset instantly.
  • Encryption is easy to add with WSS (TLS).

Comparison

  • Format: OCPP-S uses XML, OCPP-J uses JSON.
  • Transport: OCPP-S uses an HTTP request per message; OCPP-J uses a single persistent WebSocket.
  • Connection direction: In OCPP-S both sides connect to each other; in OCPP-J only the charger opens the connection.
  • Network requirements: OCPP-S usually needs a reachable IP or VPN; OCPP-J works behind NAT.
  • Data usage: Clearly lower with OCPP-J.
  • Current use: OCPP 2.0.1 and 2.1 define only JSON over WebSocket. SOAP exists only in the 1.x versions.

Which version uses which transport?

  • OCPP 1.2: SOAP only.
  • OCPP 1.5: SOAP; JSON was used later as a draft.
  • OCPP 1.6: Both 1.6S and 1.6J. The market overwhelmingly chose 1.6J.
  • OCPP 2.0.1 and 2.1: JSON over WebSocket only.

For more detail, see our article What is OCPP 1.6J.

What if you have OCPP-S chargers?

Older installations may include chargers that use SOAP. There are a few options:

  1. Firmware update: Many manufacturers have released updates that add 1.6J support to the same hardware. Ask the manufacturer first.
  2. Protocol converter (proxy): An intermediate layer that translates SOAP messages to JSON can be used. This is a temporary solution and adds maintenance overhead.
  3. Replacing the charger: If the hardware is old and no update exists, this is the cleanest long-term solution.

Many modern CSMS platforms have dropped SOAP support entirely. Üreticy also uses OCPP-J (WS/WSS) for charger connections.

The security difference

In SOAP-based installations the charger has a port open to the outside so that the central system can reach it. That port is easy to find in internet scans and increases the risk of unauthorised access. With OCPP-J there is no service exposed to the outside; the charger only makes an outbound connection. When WSS encryption is combined with a username/password or a client certificate, the connection is both private and authenticated. This is at least as important a reason for choosing OCPP-J as the data savings.

Conclusion

OCPP-S is an XML and HTTP based transport left over from the early years of the protocol. OCPP-J uses JSON and WebSocket to offer a lighter, more secure solution suited to mobile networks. If you are buying a new charger, look for OCPP-J support (1.6J, 2.0.1 or 2.1). Our guide to connecting a charger to an OCPP server walks you through the first setup step by step.