Valid YAML can fail in a converter that intentionally supports only a basic subset. Preserve the original file, reproduce the message with a sanitized working copy, and identify whether the first unsupported construct is a block scalar, anchor, alias, tag, or flow collection before deciding to edit anything.
Distinguish an unsupported feature from invalid YAML
The first useful question is whether the message says the text is malformed or that a feature is unsupported. Those outcomes require different actions: malformed text may need a syntax correction, while an unsupported feature needs a parser that implements the required YAML construct.
The current YAML ⇄ JSON converter handles nested mappings, block-style lists, quoted and plain scalars, booleans, null values, integers, and simple decimal numbers. Its code deliberately reports unsupported-feature errors for these inputs:
- Block scalars introduced by
|or>, including chomping indicators such as|-. - Anchors beginning with
&, aliases beginning with*, and explicit tags beginning with!. - Flow collections whose value begins with
[or{. - Tabs used at the start of an indented line.
These items do not all mean the same thing. Block scalars, anchors, aliases, tags, and flow-style sequences or mappings can be legitimate features in a fuller YAML implementation. A tab used for indentation is a syntax problem and should be replaced with spaces in the working copy. Do not label every rejection as “invalid YAML,” and do not label tab indentation as a valid advanced feature.
The error describes this page's accepted input, not the authority of the production configuration. The page does not load a service's schema, resolve templates, or evaluate deployment permissions.
Reduce a deployment copy to one construct at a time
A small reproduction tells you which boundary you reached without exposing or rewriting the full configuration. Make an untouched backup or rely on version control, then create a separate diagnostic copy. Replace tokens, private hostnames, account identifiers, certificates, and customer values with obvious placeholders before pasting any text into a browser tool.
Consider a deployment file that defines shared defaults with an anchor and runs a multiline shell script with a block scalar. A value such as defaults: &service_defaults introduces an anchor, settings: *service_defaults introduces an alias, and run: | introduces a block scalar. All three can be meaningful to a full YAML parser, but the ToolboxHub subset will stop at the first one it encounters.
Use a controlled reduction:
- Keep the nearest parent mapping and one representative list item.
- Remove unrelated sibling sections from the diagnostic copy, not from the source.
- Replace the block scalar temporarily with a short quoted placeholder only to test whether the next unsupported construct appears.
- Replace an anchor or alias only in the diagnostic copy, and only with a clearly marked placeholder structure whose purpose is to expose the next parser boundary.
- Restore one removed construct at a time until the first rejection is reproducible.
This process is diagnosis, not a migration plan. Expanding an alias or flattening a multiline script can change merge order, fields, newlines, or quoting. The right outcome may be to leave the YAML unchanged and use the consuming platform's full parser.
Read each reported boundary literally
Block scalar errors point to multiline content. A script, policy, or certificate can depend on preserved newlines, so removing | or > can damage meaning. Use a full parser and confirm the resulting string with the target application.
Anchor, alias, and tag errors point to node reuse or explicit type behavior. A basic JSON preview cannot safely imitate that behavior, so merge patterns belong in a full-parser path rather than a manual search-and-replace exercise.
Flow collection errors point to bracket or brace notation. A reviewed block-style rewrite may be valid, but it still needs the official parser and application validation.
Tab-indentation errors are different: indentation should use spaces. Show whitespace, replace only leading indentation tabs in a working copy, and avoid changing tabs inside quoted values or embedded scripts.
If the message instead says there is unexpected indentation, a malformed quote, an empty mapping key, or a missing mapping colon, investigate syntax near the first reported line. The actual mistake can be on the preceding line, where a parent key, quote, or list marker changed how the next line is interpreted.
Choose the next validator based on the document's owner
When a required construct is outside the browser subset, switch tools rather than weakening the file. The best next step is usually the parser, linter, schema checker, configuration preview, or dry-run command documented by the system that consumes the YAML. It knows more about supported YAML versions, custom tags, required fields, and product-specific constraints than a generic converter.
Keep the validation layers separate:
- A basic converter can reveal whether its supported subset forms nested objects and arrays.
- A full YAML parser can determine whether the required YAML constructs are syntactically valid under its implementation.
- A schema validator can reject unknown fields, missing properties, or incorrect value types after parsing succeeds.
- The owning application's preview or dry run can resolve templates and references without committing a production change.
- A test environment can expose authorization and runtime behavior that static parsing cannot predict.
Do not jump from “full parser accepted it” to “safe to deploy.” Acceptance at one layer only clears that layer. Record which command or product version performed the check, keep the output with the reviewed change, and stop if the official validator is unavailable for a high-impact configuration.
Compare only the diagnostic change and verify the result
If you do make a legitimate source correction, compare it with the untouched version before applying it elsewhere. The Text Diff tool can compare two pasted, sanitized extracts by line, word, or character. It does not parse YAML or know whether an alias resolves correctly, so use it to account for the edit, not to approve the configuration.
For example, replacing one leading tab with spaces should produce a narrow difference. If image tags, commands, endpoints, or placeholders also changed, split the work; a parser fix should not conceal a deployment change.
When the subset produces JSON, use the JSON formatter and validator to inspect nesting and types. Confirm that lists and mappings keep their shape and that "false" remains distinct from Boolean false. This still does not confirm the target schema.
Finish in the document owner's approved path: run the official parser or linter, then the schema check or dry run, and finally a non-production test where available. Preserve the source and diagnostic copy until the result is reviewed. If the only way to make the browser page accept the file is to remove a required YAML feature, the browser page is not the right validator for that document.
Frequently asked questions
Why does valid YAML with | fail to convert?
The converter deliberately rejects block scalars. A value introduced by | can be valid in a full parser, so preserve it and use the owning application's validator.
Are YAML anchors and aliases invalid?
Not inherently. They are outside this subset. Do not expand them by guesswork; confirm reused nodes and merge behavior with a full parser.
Can I rewrite [one, two] as a block list to make it work?
Only as a reviewed source change when the consuming parser treats both forms equivalently. Test it with the official parser and application dry run.
Does a tab error mean the file only needs a different converter?
Not when the tab indents YAML structure. Replace leading indentation tabs with spaces in a working copy and avoid a global replacement that changes embedded content.
Does successful YAML-to-JSON conversion prove the deployment file is valid?
No. It only proves that the supported subset produced a value. The deployment system can still reject fields, references, permissions, or runtime behavior.
Should I paste the complete production configuration into a browser tool?
Use a sanitized minimal reproduction. Remove secrets, keep only the structure needed to reproduce the boundary, and validate in the consuming application's approved environment.