Questions about YamlBox

No. The converter runs entirely in your browser using a bundled YAML parser. Your config — including secrets inside it — never leaves your device, and the tool works offline after the page loads.

Documents separated by --- are parsed individually and combined into a JSON array, one object per document. If you only want the first document, switch the multi-document option to “First document only”.

Yes. Any valid YAML 1.2 works: Kubernetes manifests, docker-compose.yml, GitHub Actions and GitLab CI pipelines, Ansible playbooks, OpenAPI specs and Helm values files. Anchors and aliases used by Helm templates are resolved to their final values.

The most common causes are tabs used for indentation (YAML only allows spaces), a colon missing after a key, or a duplicate key in the same mapping. The error panel shows the offending line and points at the column, which usually makes the problem obvious.

Comments do not exist in JSON, so they are dropped. If you need to preserve them, keep the YAML as the source of truth and treat the JSON as a build artifact.

Files up to a few megabytes convert in milliseconds. Extremely large files (tens of megabytes) depend on your device memory; a desktop browser handles them comfortably where a phone may not.

Because it was a number in the JSON source, and YAML renders numbers canonically. If the value is semantically a version or an identifier, turn on “Force quotes” so it stays a string in the YAML.

Yes. The generator quotes any key that could confuse a YAML parser and leaves plain keys unquoted, so output stays readable but unambiguous.

Yes — paste it, drop the file on the input pane, or use the File button. Multi-megabyte documents are fine in a desktop browser; the conversion itself takes milliseconds.

By default, yes — keys keep their JSON order. Enable “Sort keys” when you want a deterministic, alphabetised file that produces clean diffs in version control.

It means the parser hit a character that cannot appear where it was found — commonly a trailing comma before a closing brace, single quotes instead of double quotes, or an unquoted key. This formatter shows the line and column so you can fix it in seconds.

Both. Formatting requires a successful parse, so if the output appears, the input was valid. Any structural problem shows up as an error with its location instead of silently producing wrong output.

Files of a few megabytes render instantly. For very large documents, browser memory is the practical limit rather than the formatter — a typical laptop handles tens of megabytes without trouble.

Yes — enable “Sort keys” and keys are sorted recursively at every level. That makes files deterministic, so version control diffs only show real changes.

Never. Everything is parsed in your browser tab. You can even disconnect from the network after loading the page and the formatter keeps working.

A text diff compares lines, so reformatting or reordering keys creates noise. This tool parses both documents and compares values by path, so it reports only real semantic changes.

Yes — arrays are compared element by element. An element that exists in one document but not the other is reported as added or removed at an indexed path such as $.users[2].

Yes. Key order is irrelevant because both documents are parsed first. {"a":1,"b":2} and {"b":2,"a":1} compare as identical.

Convert them first with the YAML to JSON converter in another tab, then paste both JSON outputs here. Because the diff is structural, converting YAML to JSON first does not affect the result.

Types and structure are accurate for the sample you provide. What inference cannot know is business rules — that an age must be positive, or that a field is an enum. Treat the output as a strong starting point and add constraints by hand.

Item schemas are merged: properties present in every item become required, and properties present in only some items stay optional. Type differences produce a union such as type: ["string", "number"].

Choose draft-07 if your validator is AJV 6/7, older editors, or anything not updated recently — it has the widest support and is what most OpenAPI 3.0 tooling expects. Choose 2020-12 for new projects and AJV 8.

AJV and other validators for runtime checks, VS Code for autocomplete and validation of your JSON files, OpenAPI specs to document API responses, and CI pipelines to fail builds when a response drifts from the contract.

When the input is an array of objects, each property is checked across every item. A key missing from some items is marked optional with ?, and keys present everywhere stay required.

A null is treated as a type of its own, so a field that is sometimes a string and sometimes null is typed string | null — an honest type rather than a lie your compiler trusts.

Interfaces are the more common convention and merge well in declarations; type aliases read better for unions and intersections. Functionally, for generated data shapes, either works — match your existing codebase.

Not directly. Generate the JSON Schema from the same payload and derive a validator, or write the Zod schema by hand and use these interfaces for the static side. Types describe shape at compile time; validators protect you at runtime.

Yes. Paste or drop the JSON file — nesting is inferred recursively. Very large payloads are limited by browser memory rather than the generator itself.

A JSON null cannot be stored in a plain string or int, so a nullable field gets a pointer (*string, *int). That lets encoding/json distinguish “absent” and “present but null” without failing, which is exactly what pointer types are for.

If a value is a string in one item and a number in another, the generator uses any rather than inventing a wrong concrete type. You can then decide on a custom UnmarshalJSON if the API is really that loose.

Only for fields that were missing from at least one item in your sample. Required fields get plain tags, so round-tripping does not drop data.

Yes — tabs, alignment and field ordering follow gofmt conventions. Run gofmt -l after pasting and it should report no changes.

Yes. Nested objects become separate named structs while cycling is impossible in parsed JSON, so even deeply nested payloads generate a flat, readable set of types.

Each column is scanned across all rows. All integers become INTEGER/INT, any decimal becomes NUMERIC/DOUBLE, booleans become BOOLEAN, JSON-looking strings become TIMESTAMPTZ, and nested objects or arrays become JSONB/JSON/TEXT depending on the dialect.

It is a plain script with correctly escaped string literals, so it is safe as a starting point. Review it before running on production: you may want primary keys, indexes, NOT NULL constraints and foreign keys that the generator cannot infer.

They become a single JSON/JSONB/TEXT column holding the nested value. Relational modelling of nested structures is a design decision, so the generator does not guess joins for you.

PostgreSQL if you want JSONB and TIMESTAMPTZ, MySQL for JSON columns with DOUBLE numerics, SQLite for file-based databases and tests. The structure of the script is identical; only type names and boolean literals change.

Leading zeros are significant in identifiers such as ZIP codes, product codes and phone numbers. Type casting is therefore off by default; enable it only when every numeric-looking column really is numeric.

Correctly — the parser follows RFC 4180, so "Hopper, PhD" is one field, not two. Embedded double quotes are unescaped, and multi-line quoted values are preserved.

Yes. Delimiters are auto-detected from the first line, and you can override the choice explicitly in the options bar.

JSON Lines (one JSON object per line) is the format most data tools, log processors and LLM pipelines expect. It also streams better: each line can be processed independently.

No artificial limit — very large files are bounded only by your browser’s memory. A 50 MB CSV converts comfortably on a typical laptop.

They are flattened with dot notation, so {"customer":{"name":"Ada"}} becomes the column customer.name. Nested arrays cannot be flattened meaningfully and are serialised as JSON inside the cell.

The column list is the union of all keys across all records. A missing key simply produces an empty cell, which keeps every row aligned to the same header.

Yes. The output is standard RFC 4180 CSV with UTF-8 encoding. In Excel, use Data → From Text/CSV if double-clicking mangles encoding on older versions.

Yes — each line is parsed as one record, so JSONL input produces the same table as an equivalent JSON array.

XML allows an attribute and a child element with the same name, which JSON cannot express with one key. The @ prefix keeps attributes distinct from elements, so nothing is lost in the conversion.

When the same tag appears more than once among siblings, the values become a JSON array. A single occurrence stays a scalar or object — which is why consumers should tolerate both, or why you should normalise in your code.

Yes. Namespaced elements keep their local names, and prefix collisions are preserved as written in the source. If you need full namespace fidelity, keep the original XML alongside the JSON.

Yes — the envelope and body are converted like any other XML. For SOAP, keep casting enabled so numeric fields arrive as numbers rather than strings.

No. The .xlsx file is parsed by JavaScript in your browser tab using a bundled reader. It never leaves your device, which makes the tool safe for HR, finance and customer data.

.xlsx (Excel 2007 and later) and .csv. The legacy binary .xls format is not supported — open it in Excel and save as .xlsx or .csv first.

Cached values stored by Excel are used. If a file was saved with formulas but without cached results — rare, but possible — those cells may come through empty. Re-saving in Excel refreshes the cache.

Excel stores dates as serial numbers; the reader converts them to JavaScript dates and emits ISO strings, so "2025-03-14" arrives as text rather than 45730.

The <track> element, and every major browser player, implements the WebVTT specification. SRT is a legacy format from broadcast tooling — players that accept it usually convert internally, imperfectly.

No. The conversion is a client-side text transformation. Confidential or unreleased content never leaves the browser, which is often a contractual requirement for studios.

WebVTT does not require them, and they are optional. By default cues are renumbered sequentially; you can turn numbering off entirely.

Yes — SRT <b>/<i>/<u> tags are valid WebVTT and are preserved. SRT-specific {an8}-style positioning overrides are stripped, since WebVTT expresses positioning differently.

It tolerates the usual real-world quirks: , or . in milliseconds, one-digit hours, missing blank lines between cues with valid timecodes. Truly broken files get a clear error instead of silent corruption.

With this tool, yes for the token itself — decoding is pure JavaScript in your browser and nothing is sent anywhere. But treat tokens as secrets regardless: a JWT is a bearer credential, valid for whoever holds it until it expires. For production tokens, prefer decoding locally in your own debugger.

No, and neither does any decoder without your secret or public key. Decoding only base64url-decodes the segments. Verification requires the signing key and belongs in your backend or a library like jose or jsonwebtoken.

The usual causes are: the exp claim has passed, the token was issued for a different audience (aud) or issuer (iss), the server clock differs enough to pull nbf into the future, or the signing key was rotated. The claims panel answers the first three instantly.

iat is issued-at, exp is the expiration time and nbf is not-before. All three are Unix timestamps in seconds. A token is valid when nbf ≤ now < exp (when those claims are present).

You can edit the payload, but the signature will no longer match, so any server that verifies signatures will — correctly — reject it. For testing, re-sign with the key in your environment; that is the only way to test auth paths honestly.

By magnitude: epoch seconds are 10 digits today (1735689600), milliseconds 13 (1735689600000). The converter applies that rule, and also honours explicit decimals — 1735689600.5 is treated as seconds with a fractional part.

Both describe the same instant. UTC is timezone-independent — always safe for storage and logs. Local shows what your device’s clock displays, using the browser’s timezone, which is what a user perceives.

Almost always a timezone bug rather than a timestamp bug: a value created with a local-time parser but read as UTC (or vice versa). Compare the UTC and local rows here — if they differ by your UTC offset, that is the cause.

Yes. Negative Unix timestamps are valid and represent dates before the epoch; the converter handles them and also parses historical date strings.

The 32-bit signed integer overflow at 03:14:07 UTC on 19 January 2038 affects old systems storing timestamps as int32. In JavaScript, this tool is unaffected — and current practice of 64-bit or millisecond storage is not subject to it.

Use encodeURIComponent for a value you are placing inside a query parameter (?q=…): it escapes &, =, ?, / and # so the value cannot break the URL’s structure. Use encodeURI for a complete URL you want kept intact, which leaves :, / and ? alone.

In a path or fragment, space must be %20. In application/x-www-form-urlencoded data — the body of a classic HTML form — space is +. The query parser here treats + as a space, which is the correct behaviour for form-encoded strings.

Because it was encoded twice — often a framework encoding an already-encoded value. Decode once here; if the result still contains %-sequences, decode again, then fix the pipeline so it encodes exactly once.

Yes. Text is encoded as UTF-8 bytes and then percent-escaped, so Japanese, Arabic, Cyrillic and emoji all produce correct, interoperable URLs.

No. Base64 is an encoding, not encryption — it has no key and offers zero confidentiality. Treat Base64-encoded data as plaintext that merely looks scrambled. Use encryption (TLS, AES, age) when secrecy is needed.

Standard Base64 uses + and /, which are problematic inside URLs and identifiers. The URL-safe variant (RFC 4648 §5) substitutes - and _ and often omits the = padding, so the value survives being placed in a query string or filename.

This tool decodes to text, which is right for text payloads. If the decoded bytes are an image or archive, this decoder reports that clearly instead of printing garbage — use a bytes-to-file tool for those.

Padding. Base64 encodes 3 bytes into 4 characters; when the input length is not a multiple of three, the encoding pads with = to keep the block complete. Padding is often optional and is stripped in URL-safe usage.

The request translation is exact — method, URL, headers and body match what curl would send. What you should add before shipping: error handling (check response.ok), timeouts with AbortController, and retry logic for idempotent calls.

It is noted in a comment rather than translated, because node fetch verifies TLS by default and disabling that in code is a security decision. Fix the certificate instead; if you truly need it, set NODE_TLS_REJECT_UNAUTHORIZED=0 in a throwaway environment only.

-u user:pass becomes an Authorization: Basic header with the credentials Base64-encoded, which is exactly what curl sends. Prefer tokens over basic auth where the API supports it.

Compression is transparent in fetch, so --compressed needs no code. Redirects are followed by default in fetch, matching curl with -L; if you need manual redirect handling, set redirect: "manual".

Most failures come from unescaped quotes in complex shell strings or flags the parser does not recognise. The error names the token it choked on — usually it is quicker to fix the command than to guess.

Because README files are read in raw form at least as often as rendered form — in editors, diffs and terminals. Padded columns make the source readable, and Markdown renderers ignore the extra spaces.

Yes — paste the table; a pipe-delimited input is recognised and the existing separator row is skipped, so you get the data back without the formatting.

Yes, with a backslash (\|), which is the standard GitHub-flavoured Markdown escape. Without it, a pipe in a value would silently split the row into extra columns.

GitHub, GitLab, Bitbucket, Obsidian, Notion (via paste), Jira, most static-site generators, and any CommonMark renderer with table support. GitHub Flavored Markdown is the de-facto standard here.