IAM Policy JSON Generator

Hand-writing IAM policy JSON is a game of matching braces and remembering exactly which fields go where — Action or NotAction, a bare string or an array, whether Condition block keys are objects of objects. IAM Policy JSON Generator turns that into a form: pick an effect, list your actions and resources one per line, optionally attach a single condition, and the tool assembles a correctly-shaped statement for you — then lets you add as many statements as the policy needs before producing the final document.

Every statement you add is tracked as a row in a list below the form, showing its Sid, effect and a quick summary of how many actions, resources and conditions it carries, with a remove button so you can drop one before building the final policy. This mirrors how you actually work with a multi-statement policy in practice: you rarely write the whole thing in one pass, you add an Allow block, then a Deny block for the sensitive bits, then maybe a scoped exception, checking the shape of each one as you go.

Clicking Build assembles every statement in the list into {"Version":"2012-10-17","Statement":[...]} and immediately runs it through a structural validator. That validator is intentionally scoped: it checks that Version is present and one of the two real AWS policy language versions, that Statement exists and is not empty, and that every individual statement has a recognized Effect, an Action or NotAction, and either a Resource/NotResource or a Principal/NotPrincipal (the latter covers resource-based policies, which name a principal instead of a resource). It does not attempt to verify that the action names correspond to real AWS API operations, that the resource ARNs are syntactically valid for the services named in the actions, or anything else that would require IAM's own service-side policy grammar and simulator — this is a structural sanity check, not a substitute for testing a policy against AWS.

Above the JSON output, three stat cards summarize the built policy at a glance: total statement count, and how many are Allow versus Deny — useful for spotting at a glance whether a policy you are reviewing is mostly permissive with a few explicit denies bolted on, or the other way around. Below that sits the full pretty-printed JSON in a monospace code block, ready to copy to your clipboard or download as a .json file for attaching to an IAM role, user, or group, or for pasting into infrastructure-as-code.

The condition builder deliberately keeps to one operator/key/value block per statement rather than trying to reproduce IAM's full condition grammar (which supports multiple operators and multiple keys per statement, each with multiple values) — for the common cases, a single StringEquals, StringLike, IpAddress or Bool check against one key, it produces exactly the JSON AWS expects; for anything more elaborate, build the base statement here and hand-edit the condition block afterward, or paste your Resource/Action lists into a fresh statement per condition combination you need.

Nothing here calls any AWS API. The form assembles JSON locally and a light structural validator flags obviously incomplete statements before you copy the result out — that is the entire scope of what this page checks.

• Add-statement workflow — build one statement at a time, see it added to a running list, remove any before finalizing.
• Effect, Action/NotAction, Resource/NotResource and one Condition block per statement, matching the real IAM policy shape.
• Single values collapse to a bare string; multiple lines become a proper JSON array, matching common hand-authored policy style.
• Structural validation — Version, non-empty Statement array, per-statement Effect/Action/Resource presence checks.
• Statement summary stat cards — total, Allow count, Deny count.
• Pretty-printed JSON output in a monospace code block.
• Copy as JSON and Download .json export buttons.
• Sample policy pre-loads a realistic two-statement example.
• One-click clear resets the form and statement list.
• 100% client-side — the policy you build is never uploaded.

1. Fill in a statement — optional Sid, Effect (Allow/Deny), one action per line, one resource per line, and an optional condition (operator, key, value).
2. Click Add statement to append it to the list below the form.
3. Repeat for each additional statement your policy needs (for example a broad Allow plus a narrower Deny).
4. Remove any statement from the list if you need to redo it.
5. Click Build policy JSON to assemble the full document and run the structural validator.
6. Review the stat cards and validation result — a red banner lists any structural problems found.
7. Copy or download the resulting JSON.
8. Click Load sample at any point to see a worked two-statement example, or Clear to start over.

Example 1 — simple read-only statement. Effect Allow, actions s3:GetObject and s3:ListBucket, resources arn:aws:s3:::reports-bucket and arn:aws:s3:::reports-bucket/*, no condition — produces a two-action, two-resource array statement.

Example 2 — conditional access by IP. Effect Allow, action s3:GetObject, resource arn:aws:s3:::internal-bucket/*, condition operator IpAddress, key aws:SourceIp, value 203.0.113.0/24 — produces a statement with a nested Condition block restricting access to one CIDR block.

Example 3 — explicit deny on sensitive actions. A second statement with Effect Deny, actions iam:* and organizations:*, resource *, appended after an Allow statement — the resulting policy shows 1 Allow and 1 Deny in the stat cards.

Example 4 — MFA-gated deletion. Effect Deny, action s3:DeleteObject, resource arn:aws:s3:::reports-bucket/*, condition operator Bool, key aws:MultiFactorAuthPresent, value false — blocks deletes unless the caller authenticated with MFA.

Example 5 — invalid input caught by validation. Removing every action from a statement before adding it (leaving the actions textarea empty) still adds a statement with Action: "*", since the builder falls back to a wildcard when no actions are listed — worth double-checking before you Build if that was not intended.

• No brace-matching by hand — the form guarantees syntactically correct JSON.
• Multi-statement workflow mirrors how real policies get written, one block at a time.
• Structural validation catches obvious omissions before you paste a policy into IAM.
• Statement summary at a glance — spot an Allow/Deny mix quickly during review.
• Copy or download straight into a role, user, group, or IaC template.
• Private — policies are assembled entirely client-side.