| 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 a structured way to describe infrastructure and service settings with named blocks and attributes. As those files spread across modules and environments, small structural differences can hide missing settings, inconsistent value types, or an extra nested branch that only shows up in production. This tool turns pasted HCL into a structural view so you can inspect what the configuration contains before you move on to a deeper review.
That makes it useful for Terraform modules, Nomad job files, and other HCL-based configuration when you need to compare shape rather than reread every stanza in raw text. A reviewer can see how many documents were parsed, how many scalar leaves exist, how deep the structure runs, and which paths repeat across documents, then decide where closer attention is warranted.
A common case is checking two environment configs that should differ only by a few names or values. Instead of diffing long files line by line, you can flatten both documents into paths, see whether the same leaves exist in each one, and notice extra or missing branches quickly. That is often faster than trying to reason about nested blocks from indentation alone.
The result is still a structural interpretation of HCL text. It does not know the provider schema, module contracts, variable values, or runtime rules that decide whether a target system will accept the configuration. A clean-looking conversion also does not mean a plan, validation pass, or deployment will succeed.
Use it as a review and translation aid, not as the final verdict. The derived views are good for inspection, comparison, and handoff, while the target HCL application remains the place where semantics are confirmed.
For a first pass, paste the file into HCL content, keep Path style on dot.notation[0], and read Overview before opening the format tabs. The Document, Total nested keys, Scalar values, and Max depth rows tell you quickly whether you are dealing with one compact file, a multi-document input, or a much deeper tree than expected.
This is strongest when you want to compare structure, document a configuration in a different text format, or turn scalar leaves into Env or Properties lines for downstream review. It is a weak fit when you need provider validation, interpolation results, or policy enforcement, because the package only reflects the parsed structure it receives.
Preview trimmed appears, trust the complete table export from Paths or Schema more than the first screenful of rows.ENV prefix before copying Env output for a shared shell or deployment job, otherwise unrelated modules can normalize into confusingly similar variable names.Path style before you start comparing runs. Switching midway changes every rendered path string even when the source data did not change.One common misread is to treat converted YAML or JSON as proof that the source configuration is semantically valid. It is better to read those views as inspection aids. Before you trust a comparison, check one or two critical leaves in both Paths and Schema, and confirm that Types and Docs match the fields you actually care about.
HCL organizes configuration as nested blocks, labels, and attributes. Once parsed, this tool reduces the input to a value tree made of objects, arrays, and scalar leaves, then measures three structural quantities that matter for review: how many documents were found, how many nested keys and scalar leaves exist, and how deep the deepest branch runs. Those quantities are useful because they show whether two files are structurally comparable before you examine the fine detail.
The Overview rows come from a recursive walk over each parsed document. That walk counts keys, counts scalar leaves, records sample keys and sample values, and keeps the maximum depth seen anywhere in the tree. Empty objects and arrays are preserved in the schema map so the package can still describe shape even when a branch currently contains no scalar value.
Flattening is the core transform. Every scalar leaf becomes a Path row with a document number, a type label, and a short preview. The Schema view then groups those paths across all parsed documents and records Types, Docs, and Example. That is what makes cross-environment comparison practical: the same logical field can be checked by path instead of by its position in raw HCL.
Formatting controls only affect derived representations. JSON spacing changes whitespace in JSON output. YAML indent, Line width, Sort keys, Force quotes, Quote style, and Expand anchors affect YAML emission. Path style, ENV prefix, and Uppercase env rewrite flattened key names, not the parsed document. The HCL tab is the trimmed submitted text, not a canonical pretty-printer result.
The practical pipeline is short. The package parses the HCL text, walks each resulting document tree, emits flattened scalar paths, then reuses that flattened inventory to build schema summaries and text-based derivative views such as YAML, JSON, INI, environment variables, and properties lines.
| Output Field | Format/Unit | Meaning | Typical Use |
|---|---|---|---|
Document |
Count | Number of parsed documents in the current input. | Confirm whether the source is a single document or a bundled input. |
Total nested keys |
Count | Total key count across all nested objects. | Gauge structural size before deeper comparison. |
Scalar values |
Count | Number of terminal leaves such as strings, numbers, booleans, and nulls. | Estimate how much concrete data the document exposes. |
Max depth |
Count | Deepest branch encountered during traversal. | Spot unusually nested configuration that deserves path review. |
Path |
Rendered key path | Flattened location of one scalar leaf. | Compare exact leaf locations across files. |
Types and Docs |
Type list and count | Observed value types at a path and how many documents include it. | Find optional fields, missing leaves, and type drift. |
Only scalar leaves feed the Env, Properties, and INI-style outputs. When more than one document is present, generated environment keys gain a DOC1_, DOC2_, and similar prefix, while INI section names get a numeric suffix. That prevents one document from silently overwriting another in the derived text.
HCL parse error: and No HCL blocks detected. are hard stops. The package does not render derived views until parsing succeeds.Env, INI, and Properties keys collapse punctuation and case. Distinct HCL paths can therefore become similar-looking identifiers after flattening.Use the tool as a short structural review loop from raw HCL to cross-checkable paths.
HCL content or drop a .hcl or .tf file onto the editor. The summary area stays empty until parsing succeeds.HCL parse error: or No HCL blocks detected., fix braces, quotes, or source content before going further.Overview and confirm Document, Total nested keys, Scalar values, and Max depth match your expectation for the source.Advanced and set JSON spacing, YAML indent, Line width, and Path style for the form you want to inspect.ENV prefix and Uppercase env before checking Env, Properties, or INI text.Paths and Schema. If Preview trimmed appears, rely on the full table export rather than the visible preview.When the critical paths you care about show the expected Types and Docs values, you have a trustworthy structural snapshot to compare or hand off elsewhere.
Start with the structure summary, not the converted text. If two files should describe the same shape, Document, Total nested keys, Scalar values, and Max depth should be broadly aligned before you compare anything more detailed.
Docs greater than 1 in Schema means a path appears across multiple parsed documents. Docs of 1 marks a field that is environment-specific or missing elsewhere.Types is the fastest drift check. A path that changes from string to object or array usually deserves investigation before you reuse derived outputs.Preview trimmed limits only the on-screen table preview. It does not mean the parse was incomplete.What the result does not tell you is whether the target HCL application will accept the configuration. When provider rules, defaults, or expression semantics matter, verify one critical path in the target system after you finish the structural check here.
Paste a configuration with provider "aws" { region = "us-west-2" } and one aws_s3_bucket resource that includes a tags map. In Overview, Document stays at 1 while Top-level keys, Total nested keys, and Sample keys confirm that provider and resource blocks were parsed into one structured tree. In Schema, the bucket and tag leaves appear with scalar Types. That is the right pattern when you want to confirm structure before discussing naming, policy, or deployment behavior.
Paste two related HCL documents in one input, one for staging and one for production, and keep Path style fixed. The summary badge increases Document to 2, Schema uses Docs to show which paths exist in both files, and generated environment keys gain document prefixes such as DOC1_ and DOC2_. If a required path shows Docs as 1 instead of 2, one environment is missing it even if the raw files look superficially similar.
Drop a .tf file that is missing a closing brace after a resource block. The page stops before Overview renders and shows HCL parse error: at the top. If the parser script itself failed to load, the message changes to HCL parser unavailable. Please reload. Fixing the source and rerunning should restore the summary, which is a better trust check than copying any partial derived text.
No. The package parses HCL structure and builds inspection views, but application schemas and runtime validation still belong to the target system.
Env and Properties keys look different from the original HCL names?Flattened keys are normalized so punctuation, brackets, and path separators can be rendered as environment-style or properties-style identifiers. That is why deep HCL names often become underscore-separated or dot-based keys.
Yes. The summary shows the combined Document count, Schema records how many documents use each path through Docs, and generated environment keys are prefixed per document so values do not collide silently.
HCL tab not reformat my file?In this package, the HCL tab preserves the trimmed submitted text. Formatting controls are applied to derived YAML and JSON output, not to a regenerated canonical HCL representation.
Preview trimmed actually mean?It means the visible Paths preview has reached the configured display cap from Max preview paths. The underlying parse still succeeded, and full table exports still use every discovered path.