HCL to JSON Converter — Terraform & HashiCorp

Convert HashiCorp Configuration Language (Terraform, Packer, Nomad, Consul) to JSON in your browser. Blocks, labels, attributes, lists, maps, and heredocs — parsed locally, no upload.

Input HCL

JSON Output

What is HCL?

HCL (HashiCorp Configuration Language) is the declarative configuration syntax that powers Terraform, Packer, Nomad, Consul, and Vault. It mixes the readability of YAML with the precision of JSON — every HCL document maps cleanly to a JSON tree, which is exactly what this converter produces.

Converting HCL to JSON unlocks programmatic editing, integration with policy engines (OPA, Sentinel), cost estimators (Infracost), and CI/CD pipelines that prefer structured data. Terraform itself supports .tf.json files as a first-class alternative to .tf — useful when configuration is generated by code rather than written by hand.

How to convert HCL to JSON — 4 steps

Paste HCL. Copy any .tf, .pkr.hcl, or .nomad source. Click Load Sample to try a Terraform S3 bucket.
Click Convert. The tokenizer scans comments, strings, heredocs, identifiers, and punctuation; the recursive-descent parser emits a JSON tree.
Inspect the structure. Block labels become nested keys (resource.aws_s3_bucket.example), repeated blocks merge into arrays.
Use the output. Save as .tf.json for Terraform, or feed the JSON to your linter, cost analyser, or policy engine.

Sample input and output

HCL

resource "aws_s3_bucket" "logs" {
  bucket = "app-logs"
  tags = {
    Env = "prod"
  }
  versioning {
    enabled = true
  }
}

JSON

{
  "resource": {
    "aws_s3_bucket": {
      "logs": {
        "bucket": "app-logs",
        "tags": { "Env": "prod" },
        "versioning": { "enabled": true }
      }
    }
  }
}

In-Browser Parser

A 200-line tokenizer + recursive-descent parser runs entirely in JavaScript — no server round-trip, no upload.

Full HCL Subset

Blocks with labels, attributes, lists, maps, heredocs, comments (#, //, /*…*/), and interpolation strings are all recognised.

Private by Design

Configuration files contain ARNs, project IDs, and account names. None of it leaves your browser.

Use cases

check_circleReviewing infrastructure changes — JSON diffs are far cleaner than HCL diffs in PR tooling
check_circleCI/CD lint step: convert HCL → JSON and run schema/policy checks (OPA, Conftest, Sentinel)
check_circleGitOps generation: emit Terraform configuration from code, save as .tf.json, commit
check_circlePipeline integration with cost engines (Infracost) and inventory tools that ingest JSON
check_circleMigrating .tf to .tf.json for codegen-friendly modules
check_circleInspecting Packer, Nomad, Consul, or Vault configs in any JSON-aware editor

HCL vs JSON vs YAML for IaC

Aspect	HCL	JSON	YAML
Comments	Yes (#, //, /…/)	No	Yes (#)
Generated configs	Awkward	Trivial	Whitespace-sensitive
Human readability	Excellent	Verbose	Good
Interpolation	Native ($${var.x})	String-only	Engine-specific
Tooling	terraform fmt	Universal	yamllint

Need the inverse — JSON to HCL?

Round-trip your structured data back to HashiCorp's native syntax with the matching converter.

JSON to HCL Kubernetes Validator Dockerfile Validator

Frequently Asked Questions

What is HCL?

HCL (HashiCorp Configuration Language) is the human-friendly configuration syntax used by Terraform, Packer, Nomad, Consul, and Vault. It is a superset of JSON in spirit — every HCL document can be expressed as JSON, which is the format Terraform actually uses internally for module loading and JSON-syntax overrides.

Why convert HCL to JSON?

Three common reasons. First, programmatic editing — JSON is trivial for scripts to read and modify, while HCL needs a real parser. Second, Terraform itself accepts .tf.json files as a first-class alternative to .tf, useful when configuration is generated by code. Third, integration with non-HashiCorp tools (cost estimators, policy engines, dashboards) that read JSON.

Does this tool support all HCL features?

It supports the static configuration subset most engineers actually write: blocks with labels, attributes, strings (with escapes), numbers, booleans, null, lists, maps, comments, and heredocs. Interpolation expressions like ${var.region} are preserved as raw strings — they are evaluated by Terraform at plan time, not at parse time, so a static converter cannot resolve them.

Is the conversion lossless?

For static data — yes. Comments are stripped (JSON has no comments) and whitespace is normalised. Block labels become nested object keys, repeated blocks merge into arrays, and interpolation strings round-trip as-is. Function calls (e.g. lookup(...)) and conditional expressions are preserved verbatim as strings.

Can I run Terraform on the JSON output?

Yes — save the output as filename.tf.json and Terraform will load it alongside .tf files. Note that JSON-syntax Terraform requires interpolation in string form ("${var.x}"), which is exactly what this converter produces.

Is my HCL uploaded?

No. Tokenization and parsing happen entirely in JavaScript inside your browser. Configuration files often contain ARNs, project names, and account identifiers — none of it leaves the device. You can verify in DevTools → Network: clicking Convert produces zero requests.

How does this differ from terraform show -json?

terraform show -json runs after plan/apply and emits the full state with resolved values, references, and provider metadata. This converter operates on raw .tf source — it parses what you wrote, not what Terraform computed. Use terraform show for live state; use this tool for source-level transformation.

Does it handle multi-line strings (heredocs)?

Yes. Both <<EOT … EOT and <<-EOT … EOT (with leading-whitespace trimming) are recognised. The body becomes a regular JSON string with embedded newlines.