Kafka Config Upgrade Checker
Paste a Kafka config, pick the version you run and the one you are moving to, and see what changes. The settings that stop existing, the values that stop being accepted, and the defaults that move under a setting you never wrote down.
Kafka's own ConfigDef for all 16 releases from 2.5 to 4.1, compiled into this page. The kind is detected from the settings you paste and the report says which one it used, so override it if the guess is wrong.
Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.
The answer appears here
Paste on the left and press Check upgrade. Nothing leaves this tab.
Formatted
Results
Nothing else to flag.
No formatting problems, and nothing the rules object to. Worth remembering what that covers: this reads the file you pasted, not the account or cluster it will be applied to.
No finding matches that filter.
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Upgrading brokers and clients at the same time
The documented order is brokers first, then inter.broker.protocol.version, then clients. Doing it together turns one rollback into two.
Instead:Follow the documented sequence and pause between steps.
Leaving inter.broker.protocol.version pinned after the upgrade
The cluster runs on the old protocol indefinitely and none of the new features work, which then looks like the upgrade failed.
Instead:Raise it as a separate deliberate step once every broker is on the new version.
Assuming a removed setting fails loudly
Some removed settings are ignored rather than rejected, so the broker starts and behaves differently from the config you wrote.
Instead:Check for removals against the target version before the upgrade.
Why a Kafka upgrade breaks a config nobody edited
Three separate things change between releases, and only one of them is visible in a diff of your own files.
A setting stops existing
Kafka removes configs, and the client does not tell you in a way anybody notices. It logs one line at WARN, "The configuration 'x' was supplied but isn't a known config.", and starts. Whatever that setting was tuning goes back to the built-in behaviour. There is no error, no failed health check and nothing in a diff, because your file did not change. 4.0 removed the most at once, since it dropped ZooKeeper mode entirely.
A default moves under a setting you never wrote down
Kafka 3.0 turned the idempotent producer on by default, which changed acks from 1 to all and enable.idempotence from false to true. A producer config that mentioned neither got different durability and different throughput on the same file. 3.0 also raised the consumer session.timeout.ms from 10 to 45 seconds, and 4.0 changed the producer linger.ms from 0 to 5 milliseconds, which moves the latency profile of every default producer. None of these appear in a diff of your config, and all of them appear here.
A value stops being accepted
This is the one that does fail loudly. ConfigDef validates a value against its permitted set and throws a ConfigException at startup rather than ignoring it, so a value that was valid on the old release stops the client dead on the new one. It is the least common of the three and the easiest to fix, because the error names the setting.
Deprecated is not the same as removed
Kafka's ConfigDef carries no deprecation flag, so the only signal is the wording of the documentation. Where a setting's own description says it is deprecated, that is reported as planned work rather than a blocker, along with the release the documentation names for its removal. It is read narrowly on purpose: several settings describe some *other* thing as deprecated while being the recommended replacement themselves, and flagging those would tell you to stop using the setting you should be moving to.
What this cannot see
It reads a .properties file against Kafka's ConfigDef. It does not know your broker count, your topics, your actual throughput or which client library version you run, and it cannot tell you whether a default change matters for your workload, only that it happened. It also cannot see settings belonging to interceptors, metrics reporters or Connect plugins, and it says so rather than calling them mistakes. For the runtime questions, the producer and consumer linters on this site answer a different half.