Terraform Plan Summarizer — read a plan before you apply it

Both, and it detects which one you pasted. The first is the human-readable transcript Terraform prints — the one with +, ~, - and -/+ down the left margin — including the ANSI colour codes and CRLF line endings you get from copying a CI log. The second is terraform show -json tfplan, the machine format, which carries resource_changes, replace_paths, action_reason and output_changes and is a documented, versioned interface. The JSON is more reliable and is what to use if you can save a plan file; the text is what you actually have once a pipeline has already run. What it does NOT accept is terraform show -json of your state, or terraform validate -json output — both are common mix-ups, and both get told what they are, plus the command that produces the right thing instead.

The order of the two operations, and it decides whether you get an outage. -/+ means destroy then create: the old object is gone before the new one exists, so anything depending on it is broken for the length of that gap — seconds for a security group rule, twenty minutes for an RDS instance. +/- means create then destroy, which is what lifecycle { create_before_destroy = true } buys you: the replacement is built and only then is the old object removed. Terraform picks destroy-first by default, so +/- only appears where somebody asked for it. This page spells both orders out in words on every replacement row rather than making you decode a three-character glyph.

It marks the specific attribute whose change cannot be applied in place, so the provider has to delete the object and build a new one. It is per-attribute, and that is the useful part: engine_version on an aws_db_instance is a real upgrade you meant to do, while availability_zone or name changing by accident — from a renamed variable, a reformatted tag, a provider default that moved — is the classic surprise replacement. This page lifts every one of those attribute names out of the block it belongs to and shows them as chips on that resource row, so you never have to scroll a 400-line diff hunting for the comment.

Because Terraform counts operations, not resources, and a replacement is two operations. So a plan with one plain create and one replacement prints "Plan: 2 to add, 0 to change, 1 to destroy" — the replacement contributes to both figures. That is correct, and it is also the single most misread line in Terraform output, because "2 to add" sounds like two new things. This page shows four disjoint tiles instead: add is created outright, replace is destroyed and recreated, and nothing is ever counted twice. Terraform own accounting is then printed underneath, verbatim, so the two can be compared rather than confused.

Yes, and that is the reason this page exists in this form. There is no server behind it: the parser is JavaScript that loads into your tab and runs there, so the plan never leaves your machine — you can confirm it in your browser network tab, or by loading the page and then going offline. That matters more for plan output than for almost anything else you would paste into a web tool: a plan is full of account IDs, ARNs, subnet and CIDR ranges, IAM policy documents, security-group rules and internal DNS names. Pasting one into a chatbot hands all of that to a third party and, on the consumer tiers of most assistants, into training data.

It means the resources this page could read do not sum to the totals on Terraform own summary line, and nine times out of ten the paste is incomplete: a CI log viewer folded the middle away, a scrollback buffer cut it, or the copy started halfway down. The warning names both sets of numbers and tells you to trust Terraform. The reason it exists at all is that Terraform human-readable output is explicitly not a stable interface, so a text parser will eventually drift on a format change — and a summarizer that drifted silently would print a confident wrong total, which is worse than printing nothing. That cross-check is what makes parsing an unstable format defensible in the first place.

It means the value does not exist yet. Attributes like an ARN, an id, a generated DNS name or an IP address are assigned by the provider when the object is created, so at plan time Terraform genuinely does not know them and refuses to guess. It is not an error and not a warning — a plan for anything new is full of them. It does have one practical consequence: a resource whose input depends on an unknown value cannot be fully evaluated either, which is why you sometimes see a data source marked "read during apply" instead of resolved, and why an apply can turn out to do more than the plan showed.

Yes. OpenTofu forked from Terraform 1.5.x and kept both output formats: the text transcript uses the same symbols and the same "Plan: N to add, N to change, N to destroy" line, and tofu show -json emits the same format_version family with the same resource_changes shape. Everything on this page applies unchanged, and the version banner is read as whichever product printed it. The same holds for the wrappers that pass Terraform output straight through — Terragrunt, Atlantis, Spacelift — as long as the plan text itself is intact.

The JSON path is written against format_version 0.1 through 1.x, which spans Terraform 0.12 to 1.9 and current OpenTofu; a document with an unknown major version is accepted but carries a warning, because a renamed field would otherwise silently produce zeros. The text path is tested against the 1.5-and-later shapes, which is where "N to import" joined the summary line and where moved and import blocks appear; older output mostly parses, and anything that does not is caught by the count cross-check rather than reported as fact. The one thing this page will never do is estimate cost — prices go stale, and a stale figure printed with confidence is exactly the class of answer this site exists to replace.