HCL converted
{{ summaryPrimary }}
{{ summarySecondary }}
{{ metrics.documentCount }} {{ metrics.documentCount === 1 ? 'document' : 'documents' }} {{ metrics.totalKeys.toLocaleString() }} keys {{ metrics.totalScalars.toLocaleString() }} scalars Depth {{ metrics.maxDepth }} Path preview trimmed {{ warnings.length }} warning{{ warnings.length === 1 ? '' : 's' }}
{{ type }}
Paste HCL/Terraform text; .hcl, .tf, .tfvars, Nomad, and Packer HCL files are read as text.
{{ input_text.length.toLocaleString() }} chars Drop HCL, TF, TFVARS, Nomad, or Packer HCL onto the textarea.
Use 2 or 4 spaces for review, or Minified for compact API handoff.
Accepted range: 1 to 8 spaces per generated YAML level.
Use 0 to keep long HCL-derived scalar lines unwrapped; maximum is 240.
Useful for stable Terraform, Nomad, or Packer config diffs.
{{ yaml_sort_keys ? 'On' : 'Off' }}
Enable before exporting YAML to parsers that coerce bare values.
{{ yaml_force_quotes ? 'On' : 'Off' }}
Applies only when Force YAML quotes is on.
Writes repeated HCL-derived branches in full instead of YAML aliases.
{{ yaml_no_refs ? 'On' : 'Off' }}
Examples: resource.aws_s3_bucket.logs or resource/aws_s3_bucket/logs.
Accepted range: 50 to 2000 visible path rows; exports keep all rows.
Example: TF produces TF_RESOURCE_AWS_S3_BUCKET_LOGS_BUCKET.
Turn off only when the target dotenv loader expects lowercase names.
{{ uppercase_env ? 'On' : 'Off' }}
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 Copy
{{ row.path }} {{ row.types }} {{ row.docs }} {{ row.example }}
Tags: Data Format, Devops, Devtools
ENV Converter Convert .env files into YAML, JSON, runtime env, INI, and properties output while checking parsed lines, expansion gaps, and secret-like values.
INI Converter Convert INI or CFG text in your browser into JSON, YAML, properties, environment-variable text, and normalized INI with parser checks.
Properties Converter Convert Java .properties text into safer handoff formats, with duplicate-key warnings, path checks, and browser-side parsing.
TOML Converter Turn TOML into target config formats with parse checks, key-path ledgers, type previews, and schema sketches for safer migrations.
Customize
Advanced
:

Infrastructure configuration often has two audiences at once. People need to read it during review, incident response, migration, and pull-request work, while software needs a precise tree of blocks, labels, arguments, values, and nested collections. HashiCorp Configuration Language (HCL) sits in that middle ground. It is easier to scan than raw JSON for many Terraform, Nomad, and Packer-style files, but it still describes structured data that can be parsed, walked, compared, and serialized into other views.

A small HCL file is usually readable as plain text. Larger configuration sets become harder because the important question is not only what a line says, but where that value lives in the tree. A tag value inside one resource, a default inside a variable block, and a nested setting inside a job or provider block may all look simple in isolation. During a review, the useful facts are the path, the value type, the document coverage, and whether the same path appears consistently across related files.

Diagram showing HCL text parsed into a tree and then expressed as JSON, YAML, and flat keys

Two terms matter before converting HCL. An argument assigns a value to a name, such as a region, version constraint, or bucket name. A block groups arguments and other blocks under a type and optional labels, such as a Terraform resource type and resource name. Those labels are not decoration; they often become part of the path that identifies a value later.

Conversion is useful because the same configuration can be easier to inspect in different shapes. JSON is convenient for systems that expect objects and arrays. YAML can be easier for handoff or documentation when a reader wants indentation instead of braces. Flat key-value views help when scalar leaves need to be compared, searched, or adapted for environment-style workflows. Each view trades some readability, exactness, or reversibility, so the parsed tree and the path ledger remain the safer reference when details matter.

A parseable HCL document is not automatically valid Terraform, Nomad, or Packer configuration. HCL answers whether the text can be read as structured configuration; the target product still decides whether a block type is allowed, a provider argument exists, a variable expression is meaningful, or a plan can run with the available modules, plugins, and runtime context.

How to Use This Tool:

Start with the HCL source, confirm that parsing succeeded, then use the ledgers before relying on a copied format.

  1. Paste Terraform-style HCL into HCL content, drag a supported text file onto the editor, or choose Browse file. The input accepts .hcl, .tf, .tfvars, Nomad, Packer HCL, and plain text files.
  2. If an HCL parse error appears, fix the source first. Derived YAML, JSON, INI, env, properties, path, and schema views are not reliable until parsing succeeds.
  3. Read the summary and Block Ledger before switching tabs. Check the document count, top-level keys, total nested keys, scalar values, maximum depth, sample keys, and sample values.
  4. Use Path Ledger when exact locations matter. It shows the document number, rendered path, value type, and preview for discovered leaves, with a warning when the visible preview is capped.
  5. Use Schema Ledger for comparison work. The Docs value shows how many parsed documents contain a path, and Types highlights paths that changed shape.
  6. Open Advanced only for presentation choices. JSON spacing, YAML indentation, YAML quotes, path style, preview limit, env prefix, and uppercase env keys change the displayed or flattened output, not the HCL parse itself.
  7. Copy or download a derived view after the ledgers match your expectation. For deployment work, run the target product's own validation or plan step before treating the converted text as safe to use.

The fastest review path is usually Block Ledger, then Path Ledger, then the target format tab. That order catches missing blocks, unexpected nesting, and flattened-name surprises before the output leaves the page.

Interpreting Results:

The most important result is whether the HCL parsed into the number of documents and paths you expected. A clean YAML or JSON view is not enough by itself. If Block Ledger reports a surprising document count, a very low scalar count, or a maximum depth that does not match the visible nesting, inspect the ledgers before copying anything.

Schema Ledger is the best place to spot drift across related inputs. A path with Docs equal to 1 may be correct for an environment-specific setting, but it is a warning when every environment should define the same value. A path with multiple entries in Types deserves extra review because a structural type change can break downstream consumers even when the value preview looks harmless.

Result surface Use it for Do not overread it as
Normalized HCL A trimmed copy of the submitted HCL source. A canonical formatter or product-approved rewrite.
YAML Output and JSON Readable serialized views of the parsed document tree. Proof that Terraform, Nomad, or Packer will accept the configuration.
ENV Output and Properties Output Flat scalar paths adapted to key-value text. A round-trip-safe replacement for the original nested HCL.
Path Ledger Exact discovered paths, document numbers, value types, and previews. A complete on-screen list when the path preview is trimmed.
Schema Ledger Merged path coverage, observed types, and one example value. Provider-schema validation or deployment approval.

For final confidence, compare a suspicious path against the original HCL and then run the relevant product check. Terraform users should still use commands such as validation or planning in an initialized working directory when provider rules, variables, modules, or remote services affect the answer.

Technical Details:

HCL native syntax is built from arguments and blocks. Arguments bind names to expression values. Blocks introduce a type, optional labels, and a body that may contain more arguments or nested blocks. Terraform, Nomad, Packer, and other HCL-based systems then apply their own schemas to decide which block types, labels, arguments, and expression forms are valid in that product.

Conversion first turns source text into a parsed tree. Objects contribute named branches, arrays contribute indexed branches, and terminal values become scalar leaves. Once the tree exists, serialization and flattening are separate concerns: YAML and JSON keep nested shape, while INI, env, properties, path, and schema views depend on the rendered leaf paths.

Transformation Core:

Stage Mechanism User-visible evidence
Parse HCL text is read as structured documents. A syntax failure stops the conversion. An HCL parse error appears instead of result tabs.
Summarize Each document is counted for root type, top-level keys, total nested keys, scalar leaves, maximum depth, and samples. Block Ledger, summary badges, and type badges.
Flatten Each leaf receives a document number, rendered path, type label, raw value, and preview string. Path Ledger, flat key-value views, and row copy actions.
Merge paths Matching paths are grouped across documents by observed types, document coverage, and one representative example. Schema Ledger rows with Types, Docs, and Example.
Serialize Nested documents are emitted as YAML or JSON, and scalar leaves are emitted as INI, env, and properties text. Result tabs for review, copy, and download.

Path rendering matters because HCL labels and map keys can contain characters that are not safe in every target format. Dot notation keeps ordinary identifiers compact and uses bracket notation for awkward keys, such as a key containing a literal period. Slash notation uses slash-separated segments and escapes literal slashes inside key names. Array positions remain indexed so repeated blocks and ordered lists do not collapse into one ambiguous key.

Flat formats intentionally discard part of the nested structure. Env and properties text include scalar leaves only, not whole objects or arrays. Env names replace punctuation with underscores, may be uppercased, and may receive a prefix. Multi-document input adds document markers where needed so two scalar leaves from different documents do not silently reuse the same flat name.

Boundary Rule Review consequence
Syntax failure No derived views are built after a parse error. Fix braces, labels, expressions, or quoting before using any converted output.
Preview limit The visible path table is capped from 50 to 2000 rows. A trimmed preview needs a higher limit or exported rows for a complete path audit.
YAML settings Indentation, line width, key sorting, forced quotes, quote style, and anchor expansion affect emitted YAML text. These settings do not change the parsed HCL tree.
Large integers Integers beyond safe numeric handling may be represented as text in serialized output. Check Types and Example before using large identifiers downstream.
Product schema Terraform, Nomad, Packer, or another target system applies its own validation after parsing. A readable converted view is not the same as an accepted plan, job, image build, or deployment.

A short resource block shows the whole mechanism. In resource "aws_s3_bucket" "logs", the block type and labels identify a branch, the bucket argument becomes a scalar leaf, that leaf receives a rendered path, and the same value can then appear in nested YAML or JSON as well as flat env, properties, INI, path, and schema rows.

Privacy Notes:

Configuration files often contain values that should not be pasted into casual tools: access keys, account IDs, hostnames, network ranges, internal service names, and deployment topology. Treat every converted view as sensitive when the original file is sensitive.

  • The conversion runs in the browser after the page has loaded, but pasted text can still be exposed through your browser session, clipboard, downloads, screenshots, shared URLs, or local history.
  • Copied tables and downloaded outputs may contain the same secrets as the source, sometimes under flatter names that are easier to leak.
  • Remove or mask credentials before converting configuration that came from production, customer, or regulated environments.

Worked Examples:

Reviewing a Terraform resource:

Paste a provider block and a resource "aws_s3_bucket" "logs" block with tags. Block Ledger should report one document with top-level keys and scalar values. Path Ledger then gives the exact bucket and tag paths, while Schema Ledger shows their observed types and confirms that each path appears in one parsed document.

Comparing environment files:

Paste two related HCL documents that represent staging and production settings. The summary should move to two documents, and Schema Ledger should show whether expected paths have Docs equal to 2. A required path with Docs equal to 1 points to a missing setting, while a path with both string and number in Types points to a structural drift issue.

Checking awkward map keys:

A map key such as "net.core.somaxconn" is not a normal dot-path segment. Dot path style keeps the key visible with bracket notation, while ENV Output collapses punctuation into underscores. Use Path Ledger or Schema Ledger as the exact reference before relying on the flattened env name.

Recovering from bad syntax:

A missing closing brace, half-finished string, or malformed expression produces an HCL parse error and stops derived views. That failure is useful because partial output would be misleading. Fix the source, confirm that Block Ledger rebuilds, and then review the target format again.

FAQ:

Can I use the YAML output as Terraform configuration?

No. Terraform documents native HCL syntax and JSON syntax for configuration, not YAML configuration. Use YAML Output for inspection or handoff only unless another system explicitly accepts that YAML shape.

Does a clean conversion mean the Terraform config is valid?

No. A clean conversion means the HCL parsed into structured data. Terraform provider schemas, module references, variable values, and plan-time context still need Terraform validation or planning.

Why does the normalized HCL look almost unchanged?

Normalized HCL mirrors the trimmed source. The formatting controls affect derived YAML, JSON, flat text, and path views; they do not act as a full HCL formatter.

Why are env keys different from the original HCL names?

ENV Output is built from flattened scalar paths. Punctuation, separators, indexes, case, prefixes, and document numbers may be changed so nested values can fit key-value text.

What should I do when parsing fails?

Fix the HCL syntax before reading any result tab. An HCL parse error means the ledgers and converted formats were not rebuilt from a valid parsed tree.

Is it safe to paste secrets into HCL content?

Avoid pasting live secrets. The conversion runs in the browser, but source text and derived outputs can still appear in your clipboard, downloads, browser state, screenshots, or shared links.

Glossary:

HCL
HashiCorp Configuration Language, a structured configuration syntax used by Terraform, Nomad, Packer, and related tools.
Argument
A name and value assignment inside HCL, such as a region, version, or resource setting.
Block
A typed container with optional labels and a body that may contain arguments or nested blocks.
Label
A quoted or identifier-like value after a block type that helps name or classify the block.
Scalar leaf
A terminal value such as a string, number, boolean, null, date, or binary-like value.
Path Ledger
The discovered list of document numbers, rendered paths, value types, and value previews.
Schema Ledger
The merged list of observed paths, type coverage, document coverage, and example values.

References: