Before you minify: it probably won't do what you think
The obvious reason to minify a policy is "it's too big for AWS's size limit." For the most common case — an inline policy on a user, group, or role, or a customer managed policy — that reasoning doesn't hold. Per AWS's own IAM and STS character limits reference, stated explicitly for both: "IAM doesn't count white space when calculating the size of a policy against these limits." AWS is already evaluating your policy as if it were minified, regardless of how it's formatted when you save it. Removing the whitespace yourself changes nothing about whether it fits.
There's exactly one documented exception: session policies passed to AssumeRole. That 2,048-character plaintext limit is measured on the literal string you pass, whitespace included — for this one case, minifying is a real, effective way to fit under the limit.
What this tool actually checks
Paste a policy in and it's minified the same way any JSON minifier would — but the result is checked against all five of the limits this actually matters for, using the length AWS actually measures for each one:
- Customer managed policy (6,144 characters) and each identity's aggregate inline policy total — user (2,048), group (5,120), role (10,240) — checked against the minified length, since that's what AWS itself effectively measures.
- Passed session policy (2,048 characters) — checked against the original length as you pasted it, since whitespace counts here.
The three inline-policy quotas are aggregates across every inline policy on that identity, not a per-document limit — a single document under 10,240 characters doesn't guarantee a role's combined inline policies are, if there are several of them.
So when is minifying actually useful?
Mainly when the policy JSON is embedded inside something else that counts every byte regardless of what AWS's own IAM quotas say — a CloudFormation or Terraform template with its own size limit, a Lambda environment variable (4 KB total across all of them), an SSM Parameter Store value, or just keeping a config file or CI variable smaller. The session-policy case above is the only place minifying changes an actual AWS-enforced outcome; everywhere else, it's about the size of whatever's carrying the policy around, not the policy itself.
Note that this whitespace rule is specific to IAM policies — it doesn't generalize to every AWS policy type. AWS Organizations tag policies run the opposite way: whitespace counts toward their 10,000-character limit, so minifying one that's close to the edge genuinely helps.
FAQ
My policy shows as over a limit — now what?
For an aggregate inline-policy limit, the fix is usually splitting permissions across a managed policy instead, or attaching multiple managed policies (up to 20 per role by default) rather than growing one inline policy. For an over-limit managed policy itself, the actual content needs to shrink — fewer statements, narrower repeated ARNs replaced with a wildcard pattern, or splitting into more than one policy.
Does this validate the policy is structurally correct?
Only loosely — it checks whether the JSON parses and has a Statement field. For a real structural check (mutually exclusive elements, a missing or outdated Version), see IAM Policy Viewer.
Is my policy sent anywhere?
No — minifying happens entirely in your browser. Nothing you paste here is ever sent to a server.