Kafka Config Explorer by Version
Look a Kafka setting up in a specific release. Type, default, valid values, importance and update mode as they were in that version, plus every point at which any of them changed, from Kafka's own generated documentation.
All 16 releases from 2.5 to 4.1, scraped from the configuration tables Kafka's own ConfigDef generates. One setting name per line, and a pasted .properties line works too: everything after the first = or : is ignored.
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 Look up. 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.
Reading a default from the current documentation for an older cluster
Defaults change between releases, sometimes significantly. message.format.version, the compression default and several timeouts have all moved.
Instead:Select the version you actually run. That is the whole point of the version selector.
Assuming a setting exists in every version
Settings are added and removed. Anything ZooKeeper-related is simply gone in 4.0, which is KRaft only.
Instead:Check the since and removed information rather than assuming.
Confusing a broker setting with a topic override
Many settings exist at both levels with different names, such as log.retention.ms and retention.ms. The topic value wins and the broker value looks ignored.
Instead:Check which level you are setting, and note that a topic override survives a broker change.
Why a setting needs a version to have an answer
Type, default, valid values and importance all move between releases, and a reference that omits the version is wrong for most of them.
The answer is per release, not per setting
acks defaulted to 1 until Kafka 3.0 and to all from 3.0 onward. session.timeout.ms was 10 seconds and became 45. linger.ms was 0 and became 5 in 4.0. Any of those quoted without a version is right for some readers and wrong for others, and the reader cannot tell which they are. This page answers for the release you pick and lists every point at which a value changed, so you can see whether the number you remember was ever correct.
Not existing yet and having been removed are different answers
A setting absent from your release is either too new or gone, and what happens is different in each case: too new and the value is ignored while the older behaviour applies, gone and you are relying on something that no longer has an effect. Kafka 4.0 removed every ZooKeeper setting because it is KRaft only, so those are not discouraged there, they are absent. This page reports which of the two you have hit rather than a single unhelpful not found.
Deprecated has no flag, only prose
ConfigDef carries no deprecation field, so the only signal is the wording of a setting's own documentation. Where that says the setting is deprecated, it is reported here, along with the release the documentation names for removal when it names one. This is read narrowly on purpose: several settings describe some other thing as deprecated while being the recommended replacement themselves.
Where the data comes from
Kafka's ConfigDef generates the configuration tables in the official documentation at release time, and this dataset is scraped from those pages for all sixteen releases from 2.5 to 4.1: 930 settings across seven kinds. That makes it the primary source rather than a transcription of one. Kafka's own human reading of a duration or size default, the 7 days next to 604800000, is stored separately from the number, because a config saying 604800000 has to compare equal to its default.
What this cannot see
Only the seven ConfigDef kinds Kafka publishes tables for. Settings belonging to interceptors, metrics reporters, Connect plugins, Streams processors or a vendor distribution are not in any of them and will come back as unknown, which is a limit of the source rather than a judgement about the setting. Descriptions are stored once, from the newest release a setting exists in, because Kafka rewords them constantly and keeping every revision quadrupled the dataset.