Terraform Validator & Formatter

Paste or drop a .tf file to check whether it parses, and get the exact line of any syntax error rather than a complaint about the end of the file. Then see it formatted the way terraform fmt would write it, plus the security and cost problems worth catching before apply.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Validate & format. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

SSH open to the world

0.0.0.0/0 on port 22, found before it reaches an apply

resource "aws_security_group_rule" "all" {
  type = "ingress"
  cidr_blocks = ["0.0.0.0/0"]
  from_port = 22
  to_port = 22
}

Formatting drift

What terraform fmt would change, without running terraform

resource "aws_s3_bucket" "logs" {
  bucket   = "my-logs"
  acl = "private"
}

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Opening a management port to 0.0.0.0/0 temporarily

    Temporary rules outlive the reason for them, and scanners find port 22 within minutes of it opening.

    Instead:Use a bastion or SSM Session Manager. If a rule must be temporary, give it an expiry in the ticket and a follow-up.

  2. Putting credentials in a provider block

    They end up in version control and in state. Terraform state stores them in plain text regardless of where they came from.

    Instead:Use the provider's own credential chain: environment, profile or instance role.

  3. Treating terraform validate as a security check

    It checks syntax and internal consistency. It has no opinion about whether a bucket is public.

    Instead:Run a security scanner as a separate step. This page does the same rules without installing one.

What it checks

The rules come from the same detector library our scanner runs against live cloud accounts, narrowed to what a configuration file can honestly tell you.

Syntax errors, with the line and column

Unclosed braces and brackets reported at the line they were opened on rather than at the end of the file, mismatched delimiters, strings left unterminated at a line break, and heredocs whose terminator never arrives. Each comes with an excerpt and a caret under the character.

terraform fmt, in the browser

Two-space indentation per nesting level, = signs aligned within runs of consecutive arguments at the same depth, no tabs, no trailing whitespace, a final newline. You get the formatted file to copy, or one button to apply it in place.

Public exposure

S3 ACLs and missing public access blocks, security groups open to 0.0.0.0/0 on SSH, RDP and database ports, Azure NSG rules sourced from Internet, GCP firewall rules and buckets granted to allUsers, publicly accessible RDS and Cloud SQL instances.

Encryption and keys

Unencrypted EBS, EFS, RDS, Redshift and OpenSearch, S3 buckets with no server-side encryption configured, KMS keys without rotation, Azure disks and DynamoDB tables on platform-managed keys, state files stored without encrypt = true.

Identity and access

Inline and managed IAM policies are parsed and run through the same rules as the IAM Policy Analyzer: wildcard actions, Resource "*" on write calls, iam:PassRole with no scope, and the escalation paths that turn a limited role into an administrator.

Secrets in config

Literal passwords, tokens and private keys assigned to attributes, plus AWS access key IDs anywhere in the file. Anything referencing a variable or a data source is left alone, because that is the pattern you want.

Cost mistakes

gp2 volumes that should be gp3, previous-generation instance and machine types, CloudWatch log groups with no retention, buckets with no lifecycle rules, provisioned DynamoDB tables with no autoscaling.

Operational safety

Databases without deletion protection or backups, local Terraform state, load balancers without access logs, mutable ECR tags, EKS and AKS control planes exposed to the internet.

What a file cannot tell you

Static analysis of Terraform is a genuinely useful check, and it has a hard ceiling. It sees the resources you declared, with the values you hardcoded, at the moment you paste them.

It does not see the security group somebody widened in the console during an incident, the eight unattached volumes left behind by an autoscaling group, the snapshot that has been billing since 2023, or the IAM user with keys that have not rotated in two years. None of that is in your repository, and all of it is on your bill and in your audit scope.

That gap is the reason our product reads the account instead of the code. This tool is the part of it we can give away.

What HCL is, and what terraform fmt actually does

Terraform files are written in HCL, HashiCorp Configuration Language. It looks like a relaxed JSON with better ergonomics, and it has exactly two constructs: blocks, which have a type and some labels and a body, and arguments, which are a name and a value. Everything in a Terraform file is one or the other.

Blocks and arguments, and nothing else

A block starts with its type, takes zero or more quoted labels, and holds a body in braces. An argument is a name, an equals sign and an expression. Blocks nest. That is the entire grammar: the complexity in a Terraform file comes from the provider schema, not from the language.

resource "aws_s3_bucket" "logs" {
|        |                |     |
|        |                |     +-- body
|        |                +-------- second label: local name
|        +------------------------- first label: resource type
+---------------------------------- block type

  bucket = "my-logs"    <-- argument: name = expression

  versioning {          <-- nested block
    enabled = true
  }
}

Parsing is not validation, and neither is planning

There are three separate questions and they fail at three different times. Does the file parse, that is syntax, and it is what this page answers. Do the arguments match what the provider expects, that is terraform validate, and it needs the provider schemas downloaded by terraform init. Will the change work against your real infrastructure, that is terraform plan, and it needs credentials. A file can sail through the first and fail the second.

parse      braces, quotes, heredocs      here, instantly
validate   argument names and types      needs terraform init
plan       against real state            needs credentials

What the formatter changes, and what it never touches

terraform fmt normalises indentation to two spaces and aligns the equals signs within runs of consecutive arguments at the same nesting depth. It does not reorder arguments, rename anything, add or remove blocks, or change a single value. It is purely whitespace, which is why it is safe to run on anything and why it belongs in a pre-commit hook rather than in a review comment.

before                    after

resource "x" "y" {        resource "x" "y" {
    name = "a"              name    = "a"
    description = "b"       description = "b"
  tags = {}                 tags        = {}
}                         }

Why a heredoc is where syntax errors hide

A heredoc opens with two angle brackets and a marker, and runs until that marker appears alone on a line. The indented form uses a dash and allows the closing marker to be indented. Get the marker wrong, or leave trailing whitespace after it, and the parser swallows the rest of the file as string content, so the error is reported hundreds of lines later, at the point where the file finally stops making sense rather than where the mistake is.

policy = <<-EOT
  {"Version": "2012-10-17"}
EOT

the closing EOT must be alone on its line, with nothing after it

More terraform tools

Terraform dynamic Block Generator It is ingress.value, not each.value Terraform check and precondition Generator A failed check does not stop the apply Terraform variables.tf Generator From the var. references you already wrote Terraform Unused Declaration Linter Dead variables, locals and data sources Terraform Atlantis YAML Generator when_modified misses your modules Terraform Function Tester and HCL Console terraform console, in a tab Terraform for Expression Tester Where do the keys collide? Terraform Interpolation Tester null becomes an empty string Terraform templatefile Tester Render it before you apply it Terraform Resource Count Calculator How many objects, not how many blocks Terraform count to for_each Converter With the moved blocks it needs Terraform moved Block Generator Rename without destroying Terraform state mv Command Builder No plan, no undo Terraform target Flag Builder And why to stop using it Terraform outputs.tf Generator Outputs are not sensitive by default Terraform Remote State Data Source Generator It grants read of the whole state Terraform Provider Block Generator docker is not hashicorp/docker Terraform .gitignore Generator and Checker .terraform* eats the lock file Terraform to OpenTofu Migration Checker The state is the part to watch Terraform tfvars to JSON Converter The JSON file wins Terraform Version Constraint Parser What ~> actually allows Terraform Resource Address Parser Quote it before the shell eats it Terraform cidrsubnet Calculator newbits is added, not the target Terraform Import Block Generator The id is not the name Terraform Lock File Viewer Why CI fails and your laptop does not Terraform Variables Checker A missing value hangs CI Terraform tfvars to Env Vars Converter Lists and maps have to be JSON Terraform Deprecated Syntax Checker What a current Terraform rejects Terraform State File Viewer Read it without uploading it Terraform Plan JSON Viewer It is not redacted Terraform HCL to JSON Converter And what the conversion loses Terraform Module Source Validator version only works for the registry Terraform Backend Config Decoder Is state actually locked? Terraform Naming Convention Validator A hyphen makes a resource unreferenceable

Elsewhere on the site