When YAML-to-JSON conversion fails, preserve the original and work on the smallest sanitized copy that still produces the error. Fix the first structural problem, inspect the resulting object or array, and then use the real application's validator; changing indentation until one converter turns green can hide a different configuration mistake.
Preserve the source and reduce the failing document
Start with an untouched copy because indentation changes meaning in YAML. Remove unrelated sections from a working copy, replace credentials and private endpoints with obvious placeholders, and keep enough parent keys to reproduce the failure. Do not paste production tokens, certificates, customer data, or a complete deployment file merely to diagnose two lines.
For example, imagine a CI configuration with a jobs mapping, a build job, and a nested steps list. The error appeared after one new step was added. A useful sample keeps jobs, build, steps, and two representative list items; it does not need the real repository token, release command, or every job in the pipeline. This smaller shape makes it possible to answer whether the new line is another mapping key, a child value, or a list item.
Keep the original and reduced copy side by side. If the reduced sample no longer fails, restore one removed section at a time until the issue returns. That is more informative than reformatting the entire file because it separates a structural cause from an unrelated value or unsupported construct.
Read indentation as parent-and-child structure
Treat each indentation level as a statement about ownership. Keys aligned at the same column are peers, a more deeply indented line belongs to the preceding parent, and a dash begins a list item at its current level. Tabs should not be used for indentation; an editor can make a tab look like several spaces even though a parser sees a different character.
Before moving spaces, describe the intended structure in plain language. In the CI scenario, steps belongs to build, and every - name item belongs to steps. A run key belongs to its particular list item, so it must align with that item's other keys rather than with the dash itself or the top-level steps key.
Use a short checklist around the first reported line:
- Confirm that sibling keys begin in the same column.
- Check whether a line is a
key: valuemapping or a- valuelist item. - If a key ends at the colon, make sure the following child is indented more deeply.
- Look for a tab at the start of a line, especially in text copied from chat or a document.
- Check the line above the error for a missing colon, malformed quote, or unexpected indentation.
- Avoid changing values and indentation in the same pass unless both changes are required and reviewed separately.
A parser may report the line where the structure becomes impossible rather than the line where the mistake began. If line 14 looks correct, inspect the preceding parent and the nearest list dash instead of adding spaces to line 14 at random.
Use the basic YAML-to-JSON converter as a shape check
Paste the sanitized sample into the YAML to JSON converter and choose YAML → JSON. The current YAML ⇄ JSON tool handles a basic subset: nested mappings, lists, quoted or plain scalars, booleans, null values, integers, and simple decimals. When that subset parses, the JSON pane displays an indented representation of the resulting data.
The useful question is not merely “Did it convert?” Ask whether the JSON has the expected shape. In the CI example, jobs should be an object, build should be an object inside it, and steps should be an array whose entries are objects. If run appears beside steps instead of inside one array entry, the YAML may have parsed while expressing the wrong hierarchy.
Inspect types as well as nesting. The string "false" is different from the Boolean false, and "8080" is different from the number 8080. An empty key can become null, while an explicitly quoted empty value is a string. The converter cannot know which type the consuming application requires.
For a second syntax view, copy the generated output into the JSON formatter and validator. That page can confirm that the generated text is valid JSON and make the hierarchy easier to scan. It does not know the schema for a CI service, container platform, application manifest, or API.
Recognize when valid YAML is outside this tool's subset
A conversion error does not always mean the YAML is invalid. ToolboxHub's parser intentionally rejects block scalars such as | and >, anchors and aliases, tags, merge keys, flow-style collections that begin with braces or brackets, and tab indentation. Some of those constructs are valid in full YAML implementations but are not supported by this browser tool.
This limit matters with real configuration. A multiline shell script often uses a block scalar, and a deployment file may use an anchor to reuse defaults. Do not delete a multiline script, expand an alias by guesswork, or rewrite a production file merely to make the basic converter accept it. Preserve the original and use the parser, linter, schema validator, or safe preview documented by the application that owns the file.
The tool also works with pasted text rather than a live project. It cannot follow included files, evaluate templates, resolve environment variables, check permissions, or predict runtime behavior. A green JSON result is evidence about the reduced text's structure only.
Compare the intended fix and validate it in the consuming system
Once the sample parses into the intended shape, compare the corrected copy with the untouched sample. The text difference checker can show line, word, or character changes in pasted text. For an indentation repair, the ideal difference is narrow: a few spaces, a colon, or a quote that you can explain. If image tags, commands, endpoints, or secrets also changed, split those edits into a separate review.
Text Diff does not parse YAML or open files. It cannot prove that a line moved to the correct parent, so read the generated JSON hierarchy again after the comparison. Then apply the accounted-for change to a fresh working copy of the real file, preserving its backup or version-control history.
Finish with the smallest safe validation supported by the consumer. That might be an official lint command, schema check, configuration preview, or test environment. Separate the outcomes:
- A YAML parsing error means the text structure could not be read.
- A schema error means the structure was read but a field, type, or required value is wrong.
- An authorization error means valid configuration reached a boundary it cannot access.
- A runtime error means the accepted configuration behaved differently when executed.
Those failures require different corrections. Converting to JSON is helpful for seeing hierarchy, but it does not replace the official validation path or authorize a production change.
Frequently asked questions
Why does the error point to a line that looks correctly indented?
The parser may detect the contradiction after the original mistake. Check the previous line, its parent key, the nearest dash, and any missing colon or malformed quote before moving the reported line.
Can I indent YAML with tabs if every line looks aligned?
Do not use tabs for YAML indentation. The ToolboxHub parser rejects them at the start of indented lines, and other tooling can interpret mixed tabs and spaces differently. Configure the editor to insert spaces and show invisible characters.
Does successful YAML-to-JSON conversion prove my configuration is valid?
No. It shows that the supported subset produced a data structure. The consuming application can still reject field names, types, required values, references, permissions, or business rules.
Why does valid YAML with a multiline script fail here?
The browser tool supports a basic subset and does not handle block scalars, anchors, aliases, tags, merge keys, or flow collections. Use the validator recommended by the target platform rather than removing required YAML features.
Should I paste a complete production configuration into the converter?
Use a sanitized minimal sample instead. Remove secrets and private data, keep only the parents and list items needed to reproduce the issue, and run the final validation in the approved environment for the application.