How to normalize json keys to match your openapi property names
- Step 1Determine the schema's property casing — Open the OpenAPI spec and check the property names under
components/schemas. Most specs use camelCase or snake_case consistently — that single style is your target. - Step 2Drop the source payload — Drag the source JSON file onto the dropzone (file input, not paste). Free tier handles up to 2 MB.
- Step 3Select the schema's case — Click the matching case button. Every key in the payload is rewritten to that style at the depths Deep rename covers.
- Step 4Keep Deep rename on for nested schemas — Leave Deep rename checked so
$ref-expanded nested objects align too. Uncheck only for opaque sub-objects the schema declares as free-form. - Step 5Validate against the schema — Click Rename Keys, then validate the output against the OpenAPI schema in your toolchain. Any property whose actual name differs from the source (beyond case) will still fail — flag it for a code map.
- Step 6Move it into your API boundary — Copy or download to confirm, then implement the same case normalization in your request adapter or response serializer so payloads are always schema-cased in production.
OpenAPI property mismatch types
What the tool aligns (case) vs. what needs code (different property name). Plan column two as adapter logic.
| Source key | Schema property | Fixable by case? | Action |
|---|---|---|---|
UserName | userName | Yes | Select camelCase |
Contact-Email | contactEmail | Yes | Select camelCase |
CreatedTimestamp | createdTimestamp | Yes | Select camelCase |
email_addr | email | No | Map in code |
ts | createdAt | No | Map in code |
Same payload across the five styles
One object rendered in each case so you can match whatever your OpenAPI schema declares. There is no 'custom' option — these five are the full set.
| Source key | camelCase | snake_case | PascalCase | kebab-case |
|---|---|---|---|---|
UserName | userName | user_name | UserName | user-name |
Contact-Email | contactEmail | contact_email | ContactEmail | contact-email |
CreatedTimestamp | createdTimestamp | created_timestamp | CreatedTimestamp | created-timestamp |
apiKeyID | apiKeyId | api_key_id | ApiKeyId | api-key-id |
Cookbook
Before/after pairs from OpenAPI-alignment work. Sensitive field names anonymised. Each shows a casing fix the schema validator will accept — and one it won't.
PascalCase source to a camelCase schema
ExampleUpstream sends PascalCase; the schema declares camelCase. Pick camelCase.
Input:
{ "UserName": "sue", "ContactEmail": "sue@x.com" }
Target: camelCase
Output (schema-shaped):
{ "userName": "sue", "contactEmail": "sue@x.com" }Hyphenated source aligned to camelCase
ExampleA feed with Hyphen-Case keys won't validate against a camelCase schema until normalized.
Input:
{ "Contact-Email": "a@x.com", "First-Name": "Al" }
Target: camelCase
Output:
{ "contactEmail": "a@x.com", "firstName": "Al" }Nested $ref object aligned
ExampleDeep rename reaches into a nested schema referenced by $ref.
Input:
{ "Order": { "ShipTo": { "PostalCode": "10001" } } }
Target: camelCase
Output:
{ "order": { "shipTo": { "postalCode": "10001" } } }Property-name mismatch the validator still rejects
ExampleIf the schema property is a different word, casing alone won't satisfy validation.
Input:
{ "emailAddr": "a@x.com" }
Schema property: email
Target camelCase output:
{ "emailAddr": "a@x.com" }
emailAddr is not email — map this in code before validating.Acronym property normalized for the schema
ExampleSchemas with acronym properties; here's how casing resolves them.
Input:
{ "apiKeyID": "k1", "refreshURL": "https://..." }
Target: snake_case
Output:
{ "api_key_id": "k1", "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.
Schema property name differs by word, not case
Validation failIf the schema declares email but the source sends emailAddr, no case style produces email — the validator rejects the extra/unknown property. This tool aligns casing only. Map differing property names in code, and prune unexpected properties with json-key-filter.
Schema demands exact acronym casing
Mismatch riskIf a schema property is literally userID, the camelCase target yields userId and validation against a strict additionalProperties:false schema fails. Specific acronym casing must be handled manually — the tool folds acronyms to one lowercased word.
Two source keys collide on one property
Silent overwriteuserId and user_id both normalize to the schema's userId/user_id; one value is dropped silently. Inspect mixed-casing payloads before validating.
Free-form / additionalProperties object
Use Deep OFFIf a schema sub-object is free-form (additionalProperties: true) and its keys are data, not declared properties, deep-renaming them changes your data. Uncheck Deep rename so only declared, top-level property keys are normalized.
Array of items matching an item schema
SupportedA top-level array whose items match a schema is normalized element by element, aligning each item's properties.
Enum string values look like keys
PreservedAn enum value such as "userName" stored in a field is never altered — only keys change — so enum validation still passes.
Payload over 2 MB on free
Blocked on freeLarge payloads exceed the 2 MB free JSON limit and are blocked with an upgrade prompt. Pro raises it to 100 MB.
Invalid JSON payload
Parse errorMalformed input fails JSON.parse and produces nothing. Validate structure first with json-validator, then normalize casing.
Mixed-convention schema
Not supportedIf a schema inconsistently mixes camelCase and snake_case properties, one normalization pass can't match both. Normalize the bulk to the dominant style, then fix the outliers in code or with json-key-filter.
Frequently asked questions
Can I map a source field to a differently-named schema property?
Only if the difference is casing. UserName → userName works; emailAddr → email does not, because the words differ. Map true renames in code, and remove unknown properties with json-key-filter.
Does it follow $ref references into nested schemas?
The tool doesn't read your spec — it just normalizes keys recursively. With Deep rename on (default), nested objects (including those your spec defines via $ref) are aligned by structure. Uncheck Deep rename for free-form sub-objects.
Which case should I pick for an OpenAPI 3.0 schema?
Whatever your components/schemas property names use — typically camelCase or snake_case. The five options are camelCase, snake_case, PascalCase, kebab-case, and UPPER_SNAKE.
Can it generate the schema for me?
No — this tool only renames keys. To derive a schema from a sample payload, use json-schema-generator, then compare its property names to your OpenAPI spec.
How are acronym properties handled?
apiKeyID → api_key_id (snake) or apiKeyId (camel). A trailing acronym is folded to one lowercased word, so a schema demanding exact ID casing needs a manual fix.
Will it change enum or value strings?
No — only keys. Enum string values pass through unchanged, so enum validation is unaffected.
What if two source keys collapse to one schema property?
JSON keeps the last one written; the other value is silently dropped. Reconcile mixed-casing source keys before validating.
Does it support dot-notation to align only nested properties?
No path syntax exists. Renaming applies to all keys within the Deep rename scope — every level (on) or top level only (off).
Where should casing alignment run in production?
In a request adapter (inbound) or response serializer (outbound) at the API boundary, so handlers always see schema-cased keys. This tool is for designing and verifying that step against a sample.
Can I paste the payload?
The tool reads a dropped file rather than pasted text. Save the payload as .json and drop it on the dropzone.
Is the payload uploaded?
No. All parsing and renaming run in your browser; sensitive field names never reach JAD Apps servers.
What's the file-size limit?
2 MB 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.