In this sectionRecipes
Across the tools
Recipes
Jobs that cross two tools, each worked through as a chain of examples where one step’s result is the next step’s input.
Start from something broken
2 guidesRepair an AI answer, then type it
A model’s reply with a code fence and Python values becomes JSON, then a TypeScript interface. Its own pageRepair an AI answer, then make it a schema
Close an answer that was cut off mid-sentence, then ask OpenAI and Claude for exactly that shape next time. Its own page
Start from two files or a question
2 guidesCheck what comes next
1 guideCheck a YAML config against a schema
Read the YAML as JSON first, then validate it against the schema you already have.
Move it somewhere else
2 guidesAbout these guides
The other sections of the Guide are arranged by tool, and each page in them explains one thing that tool does. That is the right shape for learning a control, and the wrong one for most afternoons. The work that brings people here usually has two halves: a response that has to be made valid and then described as a type, a pair of exports that have to be compared and then trimmed, a spreadsheet that has to become rows in a database. Each half lives on a different page, and nothing on either page says what to do next.
A recipe is that missing join. It takes one real job from start to finish, as a chain of the same example blocks the tool sections use — the text to paste, the presses to make, the result you should see — with one difference: each block starts from what the block before it produced. The repaired text is what goes into Generate. The document you searched is the one you then convert. The YAML one block reads as JSON is the document the next block checks against a schema.
That hand-off is not left to the prose. The test suite behind these pages runs every block through the engine the site runs, and for every block after the first it checks that the document it begins with is the one the previous block’s engine gave back — not a tidied copy, not a similar document that happened to be easier to explain. If a change to an engine ever made a later step start from something the earlier step no longer produces, the build would fail rather than the recipe quietly drifting out of true.
How to read a recipe
Every recipe opens with a paragraph on the situation it is for, so you can tell within a few lines whether it is yours. After that come its steps, each one a heading, a sentence or two on why it follows the one before, and a block. The block’s first row is what the step starts from; for every step after the first, that is the previous block’s result, carried across unchanged, and the text around it says so. The last row is what you should see when you have done what the middle row says.
Under each block is a Try it link that opens the right tool — the editor, Convert, Generate or the JWT decoder — with that step’s document already in place. So you can join a recipe halfway through without repeating the steps before it, or run each step on its own to see how it behaves. The presses the steps name are still yours to make: Try it sets the stage and leaves the button to you, because the point is to see what the button does.
Each recipe ends with Where to go from here, a few links into the tool sections its steps came from. A recipe stays short by explaining only what is particular to the combination. When a step leans on something a tool does in general — how Repair decides what to fix, how a JSONPath filter is written, why a generated schema forbids extra keys — the link goes to the page that works it through properly.
Following along with your own files
The documents in these recipes were made up for them: a warehouse’s stock on two days, a list of members, a checkout service’s config, a token carrying three permissions. They are small so a whole block fits on the screen, and plausible so the steps make sense. You do not have to use them. Every step works the same way on a document of your own, and the only thing that changes is the result.
That includes files you would not paste into a website that uploads things. Nothing any recipe does leaves the browser tab: the repair, the comparison, the conversion, the generated code and the signature check are all worked out on your own machine, which is also why they keep working when the connection drops. The Around the app section says exactly what is stored between visits and for how long.
Two habits make a longer chain safer. First, rename a document before you carry it on: the name above a pane becomes the file name of a download and, on Generate, the name of the root type, so a sensible one at the start saves renaming three things at the end. Second, remember that every action in the editor is one undo. If a step turns out to be the wrong one, ⌘Z on a Mac or Ctrl+Z elsewhere takes the document back to where the previous block left it.
When there is no recipe for your job
Seven recipes cannot cover every pairing, and they are not meant to. Most jobs that are not here are two of these steps in a different order, or one of them with a different target: a recipe that converts CSV to SQL reads just as well with YAML at the start, and one that writes a TypeScript interface would write a Python class or a Go struct with a different tab chosen. Pick the recipe closest to your job, follow it with your own document, and change the one step that differs.
If what you need is a single tool rather than a chain, the four tool sections are the better starting point: the editor, Convert, Generate and the JWT decoder. Or skip the reading altogether: Open the editor and paste something in.