When you buy EV chargers or choose charging software today, you will see three OCPP versions on datasheets: 1.6J, 2.0.1 and 2.1. They share a name and a purpose, but they are not the same protocol, and the differences affect security, features and how easily you can grow your network.
This article compares OCPP 1.6J vs 2.0.1 vs 2.1 in practical terms. It explains what changed between the versions, how to run a mixed network, how to plan a migration, and what to write into your requirements when you buy chargers now.
- OCPP 1.6J is still the most widely deployed version and remains a safe baseline for basic monitoring, authorization and remote control.
- OCPP 2.0.1 is a redesign: it is not backward compatible with 1.6, but it brings built-in security, a device model and better transaction handling.
- OCPP 2.1 builds on 2.0.1 and is backward compatible with it; it adds bidirectional charging, DER control, local tariffs and payment terminal support.
- For new purchases, prefer hardware that supports 2.0.1 (or 2.1) and TLS, and a CSMS that can run all versions side by side.
A short history of the three versions
All OCPP versions are published by the Open Charge Alliance (OCA). OCPP 1.6 was released in 2015 in two variants: 1.6S, which uses SOAP, and 1.6J, which uses JSON over WebSocket. The SOAP variant is rarely used today, so in practice "OCPP 1.6" usually means 1.6J.
OCPP 2.0 followed in 2018. It contained errors that were corrected in OCPP 2.0.1, released in 2020, and 2.0.1 is the edition the industry implements. OCPP 2.0.1 was later accepted as the international standard IEC 63584 in 2024.
OCPP 2.1 was released by the OCA in January 2025 and later published by the IEC as IEC 63584-210. It is an evolution of 2.0.1 rather than a new design.
OCPP 1.6J: the proven baseline
OCPP 1.6J covers everything a typical charging network needs for daily operation. A charger announces itself with BootNotification, stays visible with Heartbeat, reports connector states with StatusNotification, and records sessions with StartTransaction, StopTransaction and MeterValues. The CSMS can send commands such as RemoteStartTransaction, RemoteStopTransaction, Reset, UnlockConnector, ChangeAvailability and ChangeConfiguration.
Version 1.6 also includes smart charging through charging profiles (ChargePointMaxProfile, TxDefaultProfile and TxProfile), offline authorization with a local list and cache, reservations and firmware updates.
Its main weaknesses are in security and structure. Security profiles were added later through the OCA security extension, so support differs between manufacturers. Configuration is a flat list of keys, and many manufacturers add their own keys or use DataTransfer for vendor-specific functions, which reduces interoperability.
OCPP 2.0.1: a redesign for security and scale
OCPP 2.0.1 keeps the same basic idea, a JSON-over-WebSocket connection between charger and CSMS, but changes many messages. The most important changes are:
- TransactionEvent: one message with the event types Started, Updated and Ended replaces StartTransaction, StopTransaction and transaction-related MeterValues. This makes session handling more consistent.
- Device model: the charger is described as components and variables. The CSMS reads and writes them with GetVariables and SetVariables instead of flat configuration keys.
- RequestStartTransaction and RequestStopTransaction: these replace the 1.6 remote start and stop commands.
- Built-in security: security profiles, certificate management and security event notifications are part of the core specification.
- Better smart charging and ISO 15118 support: the charger can pass information from the vehicle, which enables more precise charging schedules and Plug & Charge.
- Display messages and diagnostics: the CSMS can show messages on the charger screen, and error reporting is more detailed.
Because the messages are different, a 2.0.1 charger cannot talk to a CSMS that only understands 1.6, and the reverse is also true.
OCPP 2.1: new energy use cases
OCPP 2.1 is backward compatible with 2.0.1. A system that already implements 2.0.1 needs extensions, not a rewrite. The new functions focus on the role of charging in the wider energy system and on payment:
- Bidirectional charging (V2X), so a vehicle can deliver energy back to a building or the grid.
- Control of distributed energy resources (DER).
- Local cost calculation and tariffs on the charger.
- Support for payment terminals and ad-hoc payment.
- Battery swapping and improvements for ISO 15118-20.
Many of these functions depend on hardware, vehicles and local regulation. For most operators, the practical value of 2.1 today is that it is the most future-proof option.
Comparison table: OCPP 1.6J vs 2.0.1 vs 2.1
| Topic | OCPP 1.6J | OCPP 2.0.1 | OCPP 2.1 |
|---|---|---|---|
| Released | 2015 | 2020 | 2025 |
| Transport | JSON over WebSocket | JSON over WebSocket | JSON over WebSocket |
| Compatibility | Not compatible with 2.x | Not compatible with 1.6 | Backward compatible with 2.0.1 |
| Transactions | StartTransaction / StopTransaction | TransactionEvent | TransactionEvent |
| Configuration | Flat configuration keys | Device model (components and variables) | Device model |
| Security | Added later via security extension | Built in, with security events | Built in |
| Smart charging | Charging profiles | Improved, with ISO 15118 input | Further extended, incl. V2X and DER |
| Payment and tariffs | Not in core | Limited | Local cost calculation, payment terminals |
| Field deployment | Most widely deployed | Growing | Early |
Running a mixed fleet of chargers
Most real networks are mixed. Older chargers run 1.6J, newer models ship with 2.0.1, and some manufacturers offer firmware that supports both. This is normal and does not need to be a problem, if your CSMS handles each version correctly.
Check these points for a mixed network:
- The CSMS should detect the version during the WebSocket handshake and show all chargers in one dashboard, with the same status names and reports.
- Session data from 1.6 transactions and 2.0.1 transaction events should end up in the same session history and reports.
- Remote commands should be translated to the right message for each version, for example remote stop.
- Message logs should show the raw messages, so you can troubleshoot version-specific behavior.
Üreticy was built for this situation. OCPP 1.6J, 2.0.1 and 2.1 chargers connect to the same dashboard, and 2.1 chargers use the core message set they share with 2.0.1. Sessions, reports and remote commands work the same way for the operator regardless of version. See the Üreticy OCPP software page for details.
Migration advice
You do not need to replace working 1.6J chargers just because a newer version exists. A sensible approach looks like this:
- Inventory your hardware. List each charger model, firmware version and whether the manufacturer offers a 2.0.1 firmware.
- Secure what you have. Where 1.6J chargers support the security extension, move them from plain
ws://towss://with TLS. - Test before you upgrade. Update one charger per model to 2.0.1 firmware, connect it and check boot, authorization, sessions and remote commands.
- Upgrade in groups. Change the protocol version per site or model, and keep the same charge point IDs so history stays connected.
- Buy new hardware with 2.0.1 or 2.1. Let the network move forward naturally as you add sites.
What to require when buying chargers today
Put these requirements into your tender or purchase order:
- OCPP 2.0.1 support today, and a stated plan for 2.1, plus OCPP 1.6J for compatibility with existing systems.
- TLS support (security profile 2 at minimum; profile 3 if you manage certificates).
- OCA certification or documented interoperability test results.
- Firmware updates available from the manufacturer for the expected lifetime of the product.
- No dependency on the manufacturer's own cloud for basic functions.
If you are still choosing software, our checklist for choosing OCPP software explains how to evaluate a CSMS against these points.
Frequently asked questions
Is OCPP 1.6J outdated?
No. OCPP 1.6J is still the most widely deployed version and handles monitoring, authorization, sessions and remote commands well. Its main limitation is security, which depends on whether the charger supports the security extension. It remains a solid choice for existing hardware.
Can an OCPP 2.0.1 charger connect to a 1.6 server?
No. The two versions use different messages and are not backward compatible. The charger and the CSMS must use the same version. Some chargers support both versions and let you choose one in the settings.
Is OCPP 2.1 compatible with OCPP 2.0.1?
Yes. OCPP 2.1 is backward compatible with 2.0.1, so a 2.0.1 implementation can be extended to support 2.1. The core messages remain the same, and 2.1 adds new functions such as bidirectional charging and local tariffs.
Should I wait for OCPP 2.1 hardware before buying chargers?
Usually not. Chargers that support 2.0.1 today are a strong choice, especially if the manufacturer offers a path to 2.1 through firmware. Waiting delays revenue and experience, while a flexible CSMS lets you add newer hardware later.
Which version should a new charge point operator choose?
Choose hardware that supports OCPP 2.0.1 and TLS, with 1.6J as a fallback. Pair it with a CSMS that supports all current versions. This gives you security and flexibility without locking you into one hardware generation.
Run 1.6J, 2.0.1 and 2.1 chargers side by side in one dashboard. Explore Üreticy OCPP software or check the per-connector pricing.