About JSON Keyper

I'm Ashish Singh, a back-end developer, and I build and write everything on this site. JSON Keyper is a free tool for mapping the structure of JSON documents, plus a set of guides on the JSON problems I have spent real time on. It is a one-person project: there is no company behind it and no team, and when the contact page says someone will reply, that someone is me.

My Background

I have worked professionally as a back-end developer for more than four years, mostly in Java with Spring Boot, Python, and Node.js with TypeScript. Almost all of that work involves JSON, in three recurring shapes:

• Integrating third-party APIs. Consuming responses I did not design, where the documentation describes one shape and the payload has another: fields that are null on some records and absent on others, IDs that arrive as strings, arrays that are empty exactly when you need an example.
• Building REST services. Designing the JSON my own services return, and keeping the clients that consume it - typed or not - in step with it as it changes.
• Data pipelines and ETL. Moving nested JSON into tables, where every array is a decision about rows, and one unexpected field can break a load.

Each of those shaped a part of the tool. The first is why it exists at all: before I can write parsing code for an unfamiliar response, I need a full list of what is in it. The second is why it generates TypeScript types that mark optional and nullable fields separately. The third is why the flattener can collapse array indices into a schema view that pastes straight into a mapping sheet.

Where I've Worked

I started in software testing in 2020 and moved to development in November 2021. The four development roles since then have been in quite different domains, which is where most of the JSON problems on this site come from:

• Public sector (2025 - present). I build Java EE services (EJB, JAX-RS on WildFly) for a government platform, owning features from the specification through the database, the API, and the UI.
• SAP Labs India (2024 - 2025). SAP Commerce Cloud (Hybris) checkout and pricing: coupon-expiry validation, and discount calculations that had to agree with SAP's pricing engine as basket contents changed.
• Lentra AI (2023 - 2024). Spring Boot microservices for credit-card onboarding and loan decisioning, integrating third-party eKYC and OTP services. I added Resilience4j circuit breakers and fallbacks for when those providers failed, mock responses for their timeouts in test environments, and Kafka events feeding a transaction-monitoring dashboard.
• EduNext Technologies (2021 - 2023). Spring Boot REST APIs and JSP for a school ERP used by more than 600 schools, including the APIs behind its mobile apps, and the LearnOTest online test platform.
• QA InfoTech (2020). Software test engineer: writing and running test scenarios and regression-testing fixes before release.

I have a B.Tech in Information Technology from SRM Institute of Science and Technology (2019), and certifications in Java 17, testing with JUnit, and SQL. The full history is on LinkedIn.

Problems I've Had to Solve

The guides and features on this site come from a short list of problems I have hit in real systems and had to fix:

• An upstream API changing shape. A field renamed, removed, or retyped by a provider, discovered only when parsing or a data load broke. Flattening a response to its key paths and diffing it against the last known shape is the quickest way I know to see exactly what changed - see the flattener.
• Null versus missing. Code that treated an absent field and a null field as the same thing, or crashed on one of them. The null, missing, and unknown fields comparison tests how Jackson, Pydantic, and Zod handle each case.
• Unknown-property failures. A deserializer failing on a new field an API had added without notice. The same comparison shows which defaults throw, and choosing a JSON library on the JVM covers how to configure it.
• Payloads too large for memory. A response or file big enough to exhaust memory or time out. Processing large JSON files measures what each approach actually costs.

Why I Built It

For a long time my answer to "what fields are in this response?" was a throwaway script - a recursive function in whichever language I had open, rewritten each time because the last copy was in another project. Browser DevTools shows one record at a time; jq is excellent in a pipeline but awkward when you want types, collapsed arrays, and a result you can paste into a ticket. I wanted the script as a page: paste JSON, get every path, done.

I also wanted to build something real on the front end, outside the server-side work I do every day. JSON Keyper is plain HTML, CSS, and JavaScript with no framework and no build step, which keeps it fast and means the whole tool can be read in about 600 lines of script.js.

How the Site Has Grown

The site has been online since October 2024, and it has grown the way most tools do - one missing case at a time. A few milestones, all recorded in the changelog:

• October 2024 - the first version: paste JSON, get a list of dot-notation key paths.
• June 2026 - a redesign, and the first guides on the blog.
• August 2026 - six output formats instead of one, array-index collapsing, structure statistics, and parse errors that give a line and column.
• September 2026 - the Execute cURL tab for fetching live API responses, the four format pages with the tool built in, TypeScript output that distinguishes missing fields from null ones, and a JSON formatter that never changes a value.

The source code and every change to it are public on GitHub.

How I Write the Guides

There is a lot of JSON advice online that is repeated rather than checked. I try to hold the guides here to a few rules:

• Measure instead of asserting. The large-files guide reports peak memory for each approach instead of repeating that jq streams (plain jq does not). The JSON vs XML comparison measures size and parse time, and its scripts are in the repository so you can rerun them.
• Say what it ran on. Where a guide reports behaviour or numbers, it names the versions and the setup - for example, the edge-case table in What is JSON? was run in Node.js 24 and Python 3.12, so you can tell when a result may have changed.
• Say when the answer is "use something else". Every tool page has a limitations section, and the tools guide discloses that JSON Keyper is mine and recommends other tools where they fit better.
• Correct in the open. When a guide is substantially revised, its date line says so and the change is listed in the changelog.

The guides follow the work: choosing a JSON library on the JVM and JSON in Python from the service side, common REST API structures and CORS from the integration side, and large files and nested data from the pipeline side.

How It Handles Your Data

JSON you paste is parsed by JavaScript in your own browser tab and never sent anywhere - you can disconnect from the internet after the page loads and it keeps working. The Execute cURL tab is the one exception: browsers block cross-origin requests, so it routes your request through a proxy I run to reach the API you named. The proxy does not log or store anything. The privacy policy has the details, including what the site's analytics and advertising do.

What It Does Not Do

The tool is deliberately narrow. Type inference describes the sample you paste, not the API's real contract. Very large documents can exhaust a browser tab, because the full path list is held in memory. And it checks that JSON parses, not that it matches a schema - the JSON Schema guide covers that side.

How the Site Is Funded

JSON Keyper is free and needs no account. It is supported by advertising and by anyone who chooses to sponsor it on GitHub. Neither affects what the guides recommend.

Get in Touch

If the tool gets a document wrong, or a guide has a mistake, I would like to know. Use the contact page, email admin@jsonkeyper.com, or open an issue on GitHub.