JSON to HCL Converter — Generate Terraform Source

Serialise JSON into HashiCorp Configuration Language for Terraform, Packer, Nomad, and Consul. Object values become blocks, primitives become attributes — clean, formatter-friendly output.

Input JSON

HCL Output

What is JSON to HCL conversion?

JSON to HCL serialises a structured JSON document into HashiCorp Configuration Language — the human-readable syntax used by Terraform, Packer, Nomad, Consul, and Vault. The reverse direction is also supported (see HCL to JSON), making it easy to round-trip between machine-generated and human-edited configuration.

Object values become blocks, primitive values become attributes, arrays of primitives become inline lists, and arrays of objects become repeated blocks. The serializer auto-detects nested single-key objects and emits them as labeled blocks — the standard resource "type" "name" form Terraform engineers recognise on sight.

How to convert JSON to HCL — 4 steps

Paste JSON. Any JSON object will do — Terraform-shaped, Packer-shaped, or your own schema. Click Load Sample for a Terraform example.
Click Convert. The serializer walks the JSON tree and emits HCL with consistent 2-space indentation.
Copy the HCL. Save as main.tf or any other Terraform configuration file.
Optional: terraform fmt. Run the official formatter for trailing-equals alignment in attribute groups.

Sample input and output

JSON

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

HCL

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

Auto-Labeled Blocks

Nested single-key objects collapse into the standard resource "type" "name" labeled-block form Terraform expects.

Formatter-Ready

Output uses 2-space indentation, Unix line endings, and quote-escaped strings — terraform fmt is a no-op on most files.

Browser-Local

Configuration data — account IDs, project names, ARNs — never leaves your device.

Use cases

check_circleCode-generated Terraform: emit JSON from a script, then convert to readable .tf for review
check_circleIaC review workflow: regenerate HCL from canonical JSON to surface drift
check_circleCI lint step: enforce a single source of truth (JSON) and produce HCL for terraform plan
check_circleGitOps: store configuration as JSON in a database, render HCL on deploy
check_circleMigrating from cloud APIs (which return JSON) to Terraform-managed infrastructure
check_circleEducational: see how JSON values map to HCL blocks, attributes, and labels

HCL vs JSON vs YAML for IaC

Aspect	HCL	JSON	YAML
Hand-editing	Excellent	Verbose	Good
Code generation	Awkward	Trivial	Whitespace traps
Comments	Yes	No	Yes
Schema validation	Provider-driven	JSON Schema	JSON Schema
Terraform support	.tf (default)	.tf.json	No

Round-trip your IaC

Pair this with the inverse converter and the validators to keep configuration tidy at every stage.

HCL to JSON Kubernetes Validator Dockerfile Validator

Frequently Asked Questions

When would I convert JSON to HCL?

Two scenarios. First, you have generated configuration as JSON (from a script, an API, or a JSON-based tool) and want to commit it as readable .tf source. Second, you are migrating from a JSON-driven configuration system (cloud control planes, REST APIs) to Terraform and want a starting point in HCL.

How does it decide between blocks and attributes?

Object values become blocks; primitive values become attributes; arrays of primitives become inline lists; arrays of objects become repeated blocks with the same name. The serializer also collapses nested single-key objects into labeled blocks — for example { resource: { aws_s3_bucket: { example: {...} } } } becomes resource "aws_s3_bucket" "example" { ... }, the standard Terraform convention.

What if my JSON keys contain dashes or special characters?

Keys that are not valid HCL identifiers (must start with a letter or underscore, followed by letters/digits/underscores/hyphens) are automatically wrapped in double quotes. The output stays valid HCL — Terraform accepts quoted attribute names.

Can I round-trip — HCL → JSON → HCL?

For static configuration, yes. The pair of converters preserves blocks, labels, attributes, lists, and maps. Comments are not preserved (JSON has no comment syntax) and whitespace is normalised. Interpolation strings (${...}) round-trip as-is because both directions treat them as plain strings.

Will the output run with terraform fmt?

Yes. The serializer uses 2-space indentation and standard block layout. Running terraform fmt on the result is a no-op for most cases — it may align trailing equals signs in attribute groups, which is purely cosmetic.

What about HCL functions and expressions?

JSON has no notion of function calls (lookup, format, jsonencode), so any computed expression must be encoded as a string in the JSON input — typically using interpolation syntax: "value": "${lookup(var.map, "key")}". The serializer emits that string verbatim, and Terraform evaluates the expression at plan time.

Is my JSON uploaded?

No. Parsing and serialisation happen entirely in JavaScript inside your browser. Configuration with cloud account IDs, ARNs, or project names never touches a server. You can verify in DevTools → Network — clicking Convert produces zero HTTP requests.

Can Terraform also read .tf.json directly?

Yes — that is what your input already is. Use this converter when you want a human-friendly .tf file instead. JSON is best for machine-generated configuration; HCL is best for hand-edited modules and pull-request review.