IAM Policy JSON Validator
Paste an AWS IAM policy document to validate structure, Effect values, Action formats, Resource ARN patterns, and Condition block syntax. Runs entirely in your browser.
Calculations run locally in your browserIAM Policy JSON Validator
The IAM Policy JSON Validator checks AWS IAM policy documents for structural correctness, valid Effect values, Action format, Resource ARN patterns, and Condition block syntax.
• Validate an IAM policy before attaching it to a role in production
• Debug a policy that's silently not working due to structural errors
• Check NotAction/NotResource inverse logic before deploying
• Validate condition operator syntax for MFA or IP-based restrictions
How IAM Policy JSON Validator fits into production review
IAM Policy JSON Validator belongs in the pre-merge review for identity policies, resource policies, trust policies, permission boundaries, and exception snippets. The first layer is structural: Version, Statement, Effect, Action or NotAction, Resource or NotResource, Principal where applicable, Condition blocks, and valid JSON syntax. That structure determines whether AWS will parse the document, but it does not decide whether the grant is acceptable.
A real policy review has to read combinations. Allow plus NotAction can grant much more than the author intended. Resource "*" may be reasonable for list operations and reckless for write operations. Conditions can narrow a broad action only when the service actually supports the condition key. Principal in a trust policy changes who can assume a role, while Principal in a resource policy changes who can reach a resource. Those are different review questions even though both are JSON fields.
The useful output is a checklist for the next control owner. Capture whether the statement is identity-based, resource-based, trust-based, or boundary-related; which account or organization path it affects; which services are named; and whether deny statements, SCPs, session policies, or permission boundaries change the effective permission. The JSON shape is only the starting point for least-privilege review.
When this result can be misleading
Valid JSON can still be dangerous. A policy can parse cleanly while allowing iam:PassRole, sts:AssumeRole, kms:Decrypt, secretsmanager:GetSecretValue, s3:PutBucketPolicy, or organizations actions across resources that should never be broad. Mechanical validation should not be used as an approval signal for privilege. Treat it as the point where policy review begins.
Context changes the meaning of the same statement. An identity policy attached to a break-glass role, a Lambda execution role, a CI deploy role, and a human administrator role have different blast radii. A resource policy on an S3 bucket or KMS key may override assumptions made in the identity account. A deny in an SCP may prevent an apparent allow. Without attachment context, the same JSON can be harmless, blocked, or urgent.
Conditions and negations are frequent sources of false confidence. StringLike patterns, aws:PrincipalArn checks, source IP restrictions, external ids, requested region controls, and resource tags depend on request context that may not exist for every service action. NotResource and NotAction are especially easy to misunderstand because they define the complement of a set. Close the finding only after testing the effective permission path or reviewing it with the account owner.
For deploy roles and automation roles, include the pipeline or workload that uses the policy. The same statement can be tolerable for a short-lived release job and unacceptable for an always-on human role with console access.