| Field | Value | Copy |
|---|---|---|
| {{ row.label }} | {{ row.value }} |
{{ normalizedHcl }}{{ normalizedYaml }}{{ iniText }}{{ envText }}{{ propertiesText }}| Document | Path | Type | Preview | Copy |
|---|---|---|---|---|
| Doc {{ row.docIndex }} | {{ row.path || '(root)' }} | {{ formatTypeLabel(row.type) }} | {{ row.preview }} |
| Path | Types | Docs | Example |
|---|---|---|---|
| {{ row.path }} | {{ row.types }} | {{ row.docs }} | {{ row.example }} |
HCL, short for HashiCorp Configuration Language, is built to describe structured configuration with blocks, labels, arguments, and expressions. That reads cleanly in small files, but once a module or job file grows across providers, nested blocks, repeated labels, lists, and maps, the hard part is often no longer reading the text. It is confirming what shape the configuration actually has, which leaves are present, and where one environment starts to drift from another.
This converter turns that structural review into a repeatable inspection pass. You paste HCL or drop a .hcl or .tf file, then run Inspect HCL to generate a Block Ledger, mirrored HCL text, YAML, JSON, INI, env output, properties output, flattened paths, and a merged schema table. That combination is useful when you need to document a file in another text format, check which keys actually exist, or hand a configuration snapshot to someone who does not want to trace every nested block manually.
The practical value is strongest when the question is about structure rather than execution. Terraform documentation separates the low-level HCL syntax from the schema that defines which arguments and block types are valid for a specific resource or module. Nomad documentation makes the same distinction. This page helps you inspect the syntax tree you have, but it does not replace the product-specific checks that decide whether a real run, plan, or deployment will accept the configuration.
That boundary matters. A clean YAML or JSON rendering can still describe an invalid Terraform resource, a misplaced Nomad block, or a value that only fails once provider or runtime context is applied. The safe way to read these results is as a structural snapshot: a clear view of documents, paths, types, and scalar leaves that makes later validation easier, not unnecessary.
Routine parsing and conversion happen in the browser after the page loads, so the source text is not posted to a dedicated conversion endpoint by this tool. Even so, copied tables and downloaded exports can still contain secrets, tokens, addresses, or internal names from the source file. Treat the outputs with the same care as the original configuration.
HCL syntax is built around arguments and blocks. Terraform and Nomad both describe blocks as containers with typed labels and nested content, while the product schema determines which names and value types are actually valid in a given context. This page uses that lower-level structure as its starting point. It parses the submitted HCL into one or more documents, walks each document recursively, and then builds the result tabs from the parsed value tree instead of from raw text alone.
Inspect HCL.documents = parsed top-level payloads returned from the HCL parser
total nested keys = count of object keys visited across all depths
scalar values = terminal strings, numbers, booleans, nulls, dates, or byte-like leaves
max depth = deepest object or array branch reached during traversal
The Block Ledger is the quickest summary of that walk. For each parsed document it reports top-level keys or items, total nested keys, scalar values, maximum depth, sample keys, and sample values. Empty objects and arrays still appear in the structural inventory, which is important because an empty branch can still matter when you are reviewing shape or comparing environments.
The most useful transform is flattening. Each scalar leaf becomes a path row with a document number, a type, and a preview value. The Schema tab then merges those path observations across every parsed document and records the observed Types, how many Docs include that path, and one example value. That makes it much easier to spot missing leaves, type drift, or a branch that exists only in one environment.
Path rendering follows two explicit styles. Dot style uses ordinary dotted traversal and falls back to bracket notation for keys that are not simple identifiers, such as sysctl["net.core.somaxconn"]. Slash style turns the same structure into slash-separated segments and escapes literal slashes inside key names. Arrays keep their position through indexes, which matters because Terraform's JSON mapping and some nested block constructs depend on order being preserved rather than treated as an unordered set.
| View | What it shows | What to keep in mind |
|---|---|---|
HCL |
The trimmed submitted text | It is a source mirror, not a canonical formatter. |
YAML and JSON |
Serialized forms of the parsed document tree | Formatting controls change whitespace, quoting, sorting, and wrapping, not the underlying parse result. |
INI |
Scalar-only text grouped into sections from the first path segment | Section names and keys are normalized to safe lowercase tokens, and multi-document input gets numeric section suffixes. |
Env and Properties |
Scalar-only key-value projections | Punctuation is collapsed, optional prefixes are added, and multi-document input gets document prefixes to avoid silent collisions. |
Paths and Schema |
Flattened field inventory and merged path coverage | These are the best tabs for comparison work because they keep exact locations, types, and document coverage visible. |
Advanced controls only change derived output. JSON spacing affects JSON indentation. YAML indent, Line width, Sort keys, Force quotes, Quote style, and Expand anchors affect YAML emission. Path style, ENV prefix, Uppercase env, and Max preview paths change path rendering and export presentation. None of those settings change the parsed structure itself.
There are also a few hard limits worth knowing before you rely on the output. A parse error stops every derived view. Preview text is shortened for readability, so long strings and byte-like values can be clipped in tables. Very large integers may be emitted as strings in JSON to avoid unsafe number conversion. When the Paths preview is trimmed, the visible table is only the first slice of rows, but the CSV export still uses the full discovered path list.
Start with the structural tabs, not the prettier formats. When you inspect a file for the first time, read Block Ledger before you open YAML or JSON. One document with a shallow maximum depth usually means you are looking at a compact file. Multiple documents, a much larger scalar count, or an unexpected jump in depth usually means you should slow down and inspect Paths and Schema before you trust any copied export.
Use the output tabs for different jobs. YAML and JSON are good when you want a human-readable or machine-readable mirror of the parsed structure. Env, Properties, and INI are better when you want scalar-only handoff text for notes, shell work, or simple downstream review. Paths and Schema are the strongest choices for diff-style thinking because they answer concrete questions such as which field exists, what type it has, and how many documents include it.
Keep the path style fixed while you compare runs. Switching from dot style to slash style changes every rendered key string even when the source data is identical, which makes copy-pasted comparisons much noisier than they need to be. If you know you will hand paths to shell-oriented tooling or documentation that already uses slash separators, set that once at the beginning. Otherwise the default dot style is usually easier to read for HCL-heavy reviews.
Set the env prefix before you copy env output into a shared context. Without a prefix, two unrelated modules that flatten to similar names can look closer than they really are after punctuation and case are normalized. The same caution applies to INI and Properties output. Those views are convenience projections, not round-trip-safe source formats.
Be careful with Apply to editor in the YAML tab. That button places the current YAML text back into the source editor as scratch content. The inspection step itself still expects HCL input, so rerunning Inspect HCL on that YAML will usually stop at a parse error rather than create a second clean round-trip.
If the real question is whether Terraform, Nomad, or another HCL-based system will accept the configuration, use this page first to understand the structure and then run the product's own checks. HashiCorp's documentation is clear that schema-aware validation still belongs to commands such as terraform validate, terraform plan, or the equivalent tool-specific workflow.
.hcl or .tf file onto it.Path style, ENV prefix, and Uppercase env before the first run.Inspect HCL. If parsing fails, correct the source before reading any downstream output.Block Ledger for document count, nested key count, scalar count, and depth so you know whether the parse matches your expectation.Paths and Schema to inspect exact field locations, value types, document coverage, and example values.Document count tells you whether the parser found one payload or several. That matters immediately because downstream exports change once more than one document is present. YAML joins documents with separators, schema coverage starts counting across documents, env keys gain DOC1_, DOC2_, and similar prefixes, and INI section names gain numeric suffixes.
Total nested keys, Scalar values, and Max depth are best read together. A file with many keys but few scalar leaves often means you have a deep block hierarchy or many empty branches. A high scalar count with modest depth usually means broad configuration. If two environment files are supposed to be nearly identical, large differences in any of these numbers are a sign to inspect path coverage before you compare actual values.
Types in the schema table is the fastest drift signal. A path that is a string in one document and an array or object in another usually deserves immediate attention, because that is not just a value change. It is a structural change. Docs tells you whether a path appears everywhere you expect. A required field that appears in only one document is often more important than a hundred ordinary value differences.
Preview trimmed only describes the visible Paths table. It does not mean the parse was incomplete. It means the on-screen preview stopped at the configured limit and you should use the CSV export for the full inventory. The same principle applies to shortened preview values. A clipped preview can still represent a much longer scalar leaf underneath.
The result does not tell you whether provider defaults, variable interpolation, remote data, or runtime-only checks will change behavior later. Terraform's own validation reference notes that syntax and internal consistency checks are separate from remote-service validation, and Nomad's HCL reference notes that HCL parsing occurs before job submission. Read the page as a structural inspection surface, then let the target system decide execution semantics.
Paste a short Terraform snippet with one provider "aws" block and one resource "aws_s3_bucket" "logs" block that includes a tags map. Block Ledger should show a single document with a manageable depth. In Paths, leaves such as the bucket name and tag values appear as exact scalar paths. In Schema, those same leaves appear with scalar types and a document count of 1. That is the right pattern when you want to confirm structure before you talk about naming, policy, or deployment behavior.
Paste two environment variants into the same source area, for example a staging document and a production document. The summary will move from one document to two, the schema table will show which paths appear in both through the Docs count, and env output will prefix keys per document so one set of scalar values cannot silently overwrite the other. If a required path appears with Docs of 1 instead of 2, you know one environment is missing that branch even if the raw HCL still looks superficially similar.
Suppose a map includes a key such as "net.core.somaxconn". In dot-path mode, the flattened path keeps that meaning visible through bracket notation instead of pretending it was a simple identifier. In env output, the same path is normalized into an uppercase key with punctuation collapsed to underscores. That makes the export easier to reuse, but it also shows why the Paths and Schema tabs remain the safer source of truth for exact field identity.
Drop a file that is missing a closing brace or contains malformed HCL. The page will stop before it renders the derived tabs and show a parse error instead. That is the right stopping point. Fix the source first, then rerun the inspection. Partial or guessed downstream output would be less trustworthy than no output at all.
No. It parses HCL structure and builds inspection views from that structure. Product-specific schemas, argument validity, and run-time checks still belong to the target system.
HCL tab look so similar to what I pasted?Because that tab mirrors the trimmed submitted text. The formatting controls change the derived YAML and JSON views, not a canonical reprint of the HCL source.
Those exports normalize punctuation, separators, indexes, and case so nested paths can become plain text keys. That improves portability, but it also means the flattened export key is a transformed identifier rather than the exact source spelling.
Yes. Multi-document input is one of the strongest use cases for this page. Schema coverage, document counts, document-prefixed env keys, and suffixed INI sections all help keep those documents separate during review.
Apply to editor from the YAML tab?Because the source editor now contains YAML text, while Inspect HCL expects HCL input. The button is useful for scratch reuse of the YAML output, not for a second HCL parse.
The parsing and derived output generation happen in the browser after the page loads, rather than through a dedicated conversion request. The main privacy risk is still the content itself: copied tables, downloaded files, and shared exports can expose whatever secrets were present in the source text.