HCL to JSON Converter

Terraform, Packer, Consul, Nomad, and Vault all use HashiCorp Configuration Language (HCL). Every HCL document has an equivalent JSON form — useful for programmatic generation, tool interop, and validation pipelines that prefer JSON. This converter parses HCL2 in your browser and emits the canonical JSON representation Terraform itself accepts.

How to use the HCL to JSON Converter

Paste any HCL2 document — a Terraform .tf file, a Packer template, a Nomad job spec. Each top-level block (resource, variable, module, provider, etc.) maps to a key in the JSON object. Block labels stack as nested keys, attributes become property/value pairs, nested blocks become nested objects.

The output matches the JSON variant Terraform accepts: rename the file from .tf to .tf.json and Terraform will plan and apply against it identically. Expressions (interpolations, function calls, references to other resources) are emitted as JSON strings preserving the original syntax, exactly as the HCL→JSON spec requires.

About HCL to JSON Converter

HashiCorp Configuration Language was designed to read like a config file but parse like a programming language. The HCL2 spec (used by Terraform 0.12+) is two-faced on purpose: every valid HCL document has a mechanical translation to JSON, and every valid JSON document in the HCL JSON schema is a valid Terraform config. That means Terraform can consume .tf (human-friendly) or .tf.json (machine-friendly) interchangeably. You’d hand-write HCL; you’d generate .tf.json from a script or a higher-level tool like CDK for Terraform.

This converter handles the common HCL constructs: blocks with labels, nested blocks, attribute assignments, primitive values, lists, maps. Expressions inside attribute values are kept as strings since the runtime evaluation belongs to Terraform itself. Heredocs become multiline strings. Comments (#, //, /* */) are stripped because JSON has none.

Common use cases

  • Programmatic config generation — emit Terraform from a script in any language by going through the JSON form.
  • Linting and analysis — parse the JSON in your CI, validate, then write back if needed.
  • Migrating from HCL1 to HCL2 — round-trip through JSON to surface ambiguities.
  • Reading Packer / Nomad / Vault configs from non-Hashi tooling that already speaks JSON.

Frequently asked questions

Does this evaluate interpolations like <code>\${var.foo}</code>?
No \xE2\x80\x94 expressions are preserved as strings inside JSON. Terraform evaluates them at plan / apply time. That\xE2\x80\x99s the correct behaviour per the HCL JSON spec.

Can I round-trip JSON back to HCL?
Not with this tool. The official direction is HCL \xE2\x86\x92 JSON; JSON \xE2\x86\x92 HCL is lossy (formatting, comments, idiomatic block syntax). Use terraform fmt on hand-edited HCL or generate it from a higher-level DSL.

Will Terraform accept the output directly?
Yes \xE2\x80\x94 save the JSON as main.tf.json (note the double extension) in your module directory and run terraform plan. Terraform treats .tf and .tf.json as equivalent.