Gera Tools

Config File Diff (ENV / TOML / INI)

Diff two .env, .toml, or .ini config files and see key-level changes

Parse two configuration files as key-value structures — respecting sections for INI and TOML — and see a structured key-level diff of added, removed, and changed keys. Ideal for comparing deployment configs. Runs entirely in your browser. It runs free in your browser on Gera Tools, with nothing uploaded.

Last updated Source: Gera Tools

How is this different from a normal text diff?

A text diff is line-based and breaks when keys are reordered or reformatted. This tool parses each file into key-value pairs first, so reordering keys produces no false differences and you see real semantic changes only.

Config File Diff compares two configuration files at the key level instead of the line level, so you only see meaningful changes. Reordering keys, adding blank lines, or changing quoting style produces no noise. Paste an old and new .env, .ini, or .toml file and instantly see which keys were added, removed, or had their values changed — perfect for reviewing deployment configuration drift between environments.

How it works

Each file is parsed into a flat map of fully-qualified keys. For ENV files, every KEY=value line becomes one entry. For INI and TOML, a section header like [database] namespaces the keys beneath it, so host = localhost is stored as database.host. Before comparing, the parser strips inline comments (text after # or ;), trims whitespace, and removes a single matching pair of surrounding quotes from values.

The two maps are then compared by key:

  • Added — keys present only in the new file.
  • Removed — keys present only in the old file.
  • Changed — keys in both whose values differ, shown with old → new.
  • Unchanged keys are counted but not listed, to keep the output focused.

Why key-level diffing matters

A standard git diff or text-diff tool produces line-based output. If you reorder keys, add a comment, or reformat values, the diff will flag those lines as changed even though nothing meaningful changed. On a .env file with 40 keys, a “sort keys alphabetically” commit produces 40 changed lines in a text diff and zero changed lines in a key-level diff.

This also surfaces the real risks more clearly. Consider these two .env files:

Old file:

DATABASE_URL=postgres://prod-db:5432/app
REDIS_URL=redis://localhost:6379
DEBUG=false

New file:

DEBUG=false
DATABASE_URL=postgres://staging-db:5432/app
REDIS_URL=redis://localhost:6379

A text diff shows three changed lines (key order shifted). The key-level diff shows one changed value: DATABASE_URL changed from the prod host to the staging host. That is the one thing that actually matters.

Common use cases

Staging to production comparison — verify that your staging .env only differs from production in the keys you expect, and that you have not accidentally promoted staging credentials or feature flags.

Deployment audit — compare the config before and after a deployment to confirm exactly what changed, for incident review or change management.

New-hire onboarding — compare .env.example against the actual .env a developer is running locally to catch missing or stale keys that would cause silent failures.

Secrets rotation — confirm that the rotated key was updated in the right environments, and that no other unexpected keys changed alongside it.

Tips and notes

Pick the format that matches your files so sections are interpreted correctly — using ENV mode on an INI file will treat the [section] line as a malformed entry. Because comparison is value-based after normalisation, DEBUG=true and DEBUG = "true" are equal. Everything runs locally, which matters because config files frequently contain API keys and database passwords.