Kafka Default Config Reference
Every Kafka default for a release you choose, as a table. Filter by name or importance, or ask only for the defaults that changed from the previous release, which is the list worth reading before an upgrade.
All 16 releases from 2.5 to 4.1, from the tables
Kafka's own ConfigDef generates. The box below filters by name: leave it
empty for every setting, or type something like replica or
ssl. to narrow it.
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 Show defaults. 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 without checking the version
Defaults move between releases, and a setting you never edited can change behaviour on upgrade. That is the most common source of surprise after an upgrade.
Instead:Select your version. The whole dataset is versioned for this reason.
Assuming an unset config equals the documented default
A broker command line argument or a dynamic config can override it while the file says nothing.
Instead:Check kafka-configs --describe for what is actually in effect.
Copying a default into your config file to be explicit
It pins the value across future upgrades, so an improved default never reaches you and the pin is invisible in review.
Instead:Leave defaults unset unless you are deliberately overriding them.
The defaults that changed under configs nobody edited
A changed default only affects the configs that never set the value, which is exactly why it goes unnoticed: your file did not change and the behaviour did.
This is the list to diff against before an upgrade
Tick changed only and the table becomes every default that moved between the release before your selection and your selection. Kafka 3.0 is the big one: enable.idempotence went false to true, which took acks from 1 to all, and the consumer session.timeout.ms went from 10 seconds to 45. Kafka 4.0 moved the producer linger.ms from 0 to 5 milliseconds, which changes the latency profile of every producer that never mentioned it. None of that appears in a diff of your own config.
Importance is Kafka's own ranking, not ours
Every setting carries a high, medium or low importance in ConfigDef, and it is the field the official tables sort by. Filtering to high gives the settings Kafka itself considers worth understanding before running in production, which for the broker is a couple of dozen rather than several hundred. It is a reasonable reading order for someone new to a config kind.
The reading beside a number is Kafka's, and it is stored separately
Kafka's documentation prints 604800000 (7 days) for a duration default. Those two facts are stored apart here, and shown on separate lines, for a specific reason: a config file saying 604800000 has to compare equal to its default, and leaving the words in the value made 110 settings look like they changed default in 2.6 when only the documentation had.
Absent is not the same as defaulted
A setting only appears in the table for a version it actually exists in. Kafka 4.0 is KRaft only, so every ZooKeeper setting is missing from it rather than present with a default, and a table that filled those in from an older release would be inventing values. Where a default is genuinely unset in ConfigDef, the row says none rather than guessing at what the code does.
What this cannot see
Only the seven kinds Kafka publishes ConfigDef tables for. Nothing from interceptors, metrics reporters, Connect plugins or a vendor distribution is in the source, so those settings are absent rather than wrong. It also cannot tell you whether a changed default matters for your workload, only that it changed; for that, the config upgrade checker on this site reads your actual file against two releases.