How to normalize json key casing to match your api contract
- Step 1Read the contract's casing convention — Open the API contract and note which case the field names use — most REST contracts pick camelCase or snake_case and stay consistent. That single style is your target.
- Step 2Drop the source payload — Drag the upstream JSON file onto the dropzone (file input, not paste). Free tier handles up to 2 MB.
- Step 3Select the contract's case — Click the matching button in the Target case style row. Every key, at every level, will be rewritten to that style.
- Step 4Keep Deep rename on for nested bodies — Leave Deep rename checked so nested request bodies are aligned too. Uncheck it only if a nested object is an opaque passthrough that must keep its original keys.
- Step 5Run and compare against the contract — Click Rename Keys and read the output against the contract field list. Any field whose WORDS (not just case) differ from the contract will still be wrong — note those for a code-side map.
- Step 6Lift the result into middleware — Copy the output to validate end-to-end, then implement the same case normalization in your request/response adapter so it runs automatically in production.
Casing mismatch vs word mismatch
What this tool can and cannot align. It fixes case differences only; differences in the underlying words need a code-side mapping.
| Upstream key | Contract field | Tool can align? | Why |
|---|---|---|---|
userId | user_id | Yes (snake_case) | Same words, different case |
First-Name | firstName | Yes (camelCase) | Same words, hyphen + case differ |
APIToken | api_token | Yes (snake_case) | Acronym splits before next word |
acct | account_id | No | Different words — needs a code map |
ts | created_at | No | Different words / semantics |
Same payload, each contract style
One source object rendered into each of the five available case styles so you can match whatever the contract declares.
| Source key | camelCase | snake_case | PascalCase | kebab-case |
|---|---|---|---|---|
userId | userId | user_id | UserId | user-id |
First-Name | firstName | first_name | FirstName | first-name |
createdAt | createdAt | created_at | CreatedAt | created-at |
APIToken | apiToken | api_token | ApiToken | api-token |
Cookbook
Before/after pairs from contract-alignment work. PII anonymised. Each shows a casing mismatch the tool fixes — and one it can't.
Legacy hyphen-case payload to a camelCase contract
ExampleA legacy feed uses Hyphen-Case keys; your contract is camelCase. Pick camelCase.
Input:
{ "User-Id": 1, "First-Name": "Alice" }
Target: camelCase
Output:
{ "userId": 1, "firstName": "Alice" }Mixed upstream casing unified to snake_case
ExampleThe upstream is inconsistent — some camelCase, some snake. Normalize to the contract's snake_case.
Input:
{ "userId": 1, "first_name": "Alice", "LastName": "Ng" }
Target: snake_case
Output:
{ "user_id": 1, "first_name": "Alice", "last_name": "Ng" }Nested request body aligned at every level
ExampleDeep rename (default on) reaches into nested contract objects.
Input:
{ "orderId": 9, "shipTo": { "postalCode": "10001" } }
Target: snake_case
Output:
{ "order_id": 9, "ship_to": { "postal_code": "10001" } }Word mismatch the tool cannot fix
ExampleWhen the upstream word differs from the contract word, case normalization won't help.
Upstream:
{ "acct": 1 }
Contract wants: account_id
Target snake_case output:
{ "acct": 1 } (already lowercase, unchanged)
acct is not account_id — map this one in code.Acronym in a token-style field
ExampleAuth payloads often carry acronym keys; here's how they normalize.
Input:
{ "APIToken": "abc", "refreshURL": "https://..." }
Target: snake_case
Output:
{ "api_token": "abc", "refresh_url": "https://..." }Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
Contract renames the actual word
Out of scopeIf the contract field name uses different words than the upstream (acct vs account_id, ts vs created_at), no case style will produce it. This tool aligns casing only. Handle word-level renames in your adapter, and use json-key-filter to drop fields the contract doesn't accept.
Two upstream keys collide on one contract field
Silent overwriteuserId and user_id both normalize to user_id; the later value overwrites the earlier and one is dropped with no warning. Inspect mixed-casing payloads before sending them downstream.
Contract uses PascalCase (e.g. .NET style)
SupportedSome contracts (notably .NET/SOAP-derived) use PascalCase. Select PascalCase and keys like userId become UserId, firstName become FirstName.
Acronym casing not preserved
By designIf a contract field is exactly userID with that capitalization, this tool's camelCase target yields userId, not userID — the trailing acronym is folded. Contracts that demand specific acronym casing need a manual override.
Nested opaque passthrough object
Use Deep OFFIf a nested object is forwarded verbatim to another service, deep-renaming its keys breaks that downstream. Uncheck Deep rename to align only the top-level contract keys.
Array request body
SupportedA top-level array of objects (e.g. a batch request) is normalized element by element, each matching the contract item shape.
Values that look like keys
PreservedA value such as "firstName" stored in a field is never touched — only keys are rewritten, so enum-like string values stay intact.
File exceeds 2 MB on free
Blocked on freeLarge payloads exceed the free JSON limit and are blocked with an upgrade prompt. Pro raises it to 100 MB.
Malformed payload
Parse errorTruncated or non-JSON input fails JSON.parse and produces nothing. Validate the payload first with json-validator.
Frequently asked questions
Can I define a from-to field map like userId → user_identifier?
No. This tool normalizes casing only; it has no free-text mapping input. userId can become user_id, but not user_identifier. For word-level renames, do it in your adapter code; to drop or keep specific fields, use json-key-filter.
Does it support dot-notation to rename only nested keys?
No. There is no path syntax. Renaming applies to all keys at the depths covered by the Deep rename setting — either every level (on) or just the top level (off).
Which case should I pick for a REST contract?
Match whatever the contract declares — most use camelCase or snake_case consistently. The five options are camelCase, snake_case, PascalCase, kebab-case, and UPPER_SNAKE.
Will it align nested request/response bodies?
Yes, with Deep rename on (the default). Uncheck it for opaque passthrough sub-objects that must keep their original keys.
What about acronyms like API or ID?
APIToken → api_token, userId → user_id. A trailing acronym is folded to a single lowercased word; specific acronym capitalization (e.g. userID) is not preserved.
Can it change values, like normalizing enum strings?
No — only keys. Values are passed through unchanged. For value-level changes, use a transformation step in code.
How do I catch fields the contract doesn't accept?
Compare the renamed output to the contract field list; case-aligned but word-different fields stand out. Remove unexpected fields with json-key-filter before sending.
Two source keys collapse to one contract field — what happens?
JSON keeps only one (the last written); the other value is silently dropped. Reconcile mixed-casing source keys first.
Can I paste the payload?
The tool reads a dropped file rather than pasted text. Save the payload to a .json file and drop it on the dropzone.
Where should renaming live in production?
Put case normalization in a request adapter (inbound) or response serializer (outbound) at the API boundary, so your core handlers always see contract-cased keys. This tool is for designing and verifying that step.
Is the payload uploaded?
No. All renaming runs in your browser; nothing reaches JAD Apps servers.
What's the size limit?
2 MB per file on free, 100 MB on Pro, higher on Pro+Media and Developer tiers.
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.