RBAC Permission Matrix Generator
Define your access matrix
in under 60 seconds.Enter roles and permissions, toggle a checkbox grid, export to CSV, Markdown, or JSON. No account. No backend. Ephemeral by design.
No account requiredClient-side onlyExport CSV, Markdown, JSONUp to 50 roles x 100 permissions
InputsStep 1
RolesOne per line or comma-separated. Max 50.
PermissionsOne per line or comma-separated. Max 100.
Permission MatrixRoles: 0Permissions: 0Checked: 0
Enter roles and permissions, then click Generate Matrix
RBAC reference
RBAC reference: starter templates, model comparison, permission verbs, export formatsThe matrix builder above lets you check permissions against roles and export to Markdown, CSV, or JSON. The reference below covers four ready-to-use RBAC templates for common application shapes, a quick-decision grid for picking RBAC vs ABAC vs PBAC, the standard permission vocabulary, and the structure of each export format with examples.
Quick-decision grid: RBAC vs ABAC vs PBACIf your access decisions need...Use
To depend only on the user's role(s)RBAC (Role-Based)
To depend on attributes of the user, resource, or environment (department, time of day, IP range)ABAC (Attribute-Based)
To be expressed as policies in a high-level language (Rego, Cedar) and evaluated at runtimePBAC (Policy-Based)
To depend on the user's relationship to the resource (owner, collaborator, viewer)ReBAC (Relationship-Based, e.g., Google Zanzibar)
To combine multiple of the aboveHybrid; most production systems are RBAC + ABAC
RBAC is the default starting point. Add ABAC when role explosion sets in (you have 50+ roles to express simple distinctions like "engineer in EU region"). Move to PBAC or ReBAC when access logic involves complex policy or graph-shaped relationships (Google Drive sharing, GitHub repo permissions).
Standard permission verbs (CRUD + extensions)VerbMeaningCommon alternatives
readView resource contentview, get, list
createAdd new resourceadd, insert, post
updateModify existing resourceedit, patch, put, modify
deleteRemove resourceremove, destroy
listEnumerate resourcesindex, query
shareGrant access to othersinvite, add_collaborator
transferChange ownershipassign, reassign
approveAuthorize a workflow stepsign_off, validate
exportExtract data outside the systemdownload, extract
auditView access logs / historyview_audit_log, inspect
adminFull control of the resourcemanage, owner
The read / create / update / delete core (plus list) covers ~80% of business application permissions. Reach for the others when the domain genuinely needs them.
Template 1: SaaS B2B app (4 roles × 8 permissions)Common starting point for multi-tenant SaaS. Each customer has their own tenant; users inside a tenant have one of these roles.
PermissionOwnerAdminMemberViewer
account.read
account.update
billing.read
billing.update
users.invite
users.remove
data.read
data.write
Owner is exactly one user per tenant. Admin can manage users but not billing (so a fired admin can't remove the credit card). Member is the working role most users have. Viewer is read-only; useful for stakeholders who shouldn't edit.
Template 2: Content management system (5 roles × 10 permissions)Editorial workflow with draft/review/publish stages.
PermissionSuper AdminEditorAuthorContributorSubscriber
posts.create
posts.edit_own
posts.edit_others
posts.publish
posts.deleteown onlyown only
comments.moderate
media.upload
users.manage
themes.manage
comments.read
Mirrors WordPress's role structure. Contributor can write but not publish (Editor must approve). Author can publish their own posts but not others'.
Template 3: E-commerce platform (4 roles × 12 permissions)Storefront with order management and customer service workflows.
PermissionOwnerManagerCustomer ServiceFulfillment
products.create
products.edit
products.delete
orders.read
orders.update_status
orders.refund
orders.cancel
customers.read
customers.edit
inventory.read
inventory.adjust
reports.financial
Customer Service can refund and cancel orders but can't adjust inventory directly (prevents fraud). Fulfillment can adjust inventory (mark items as picked/shipped) but can't issue refunds.
Template 4: Internal corporate tool (5 roles × 8 permissions)Read-mostly internal app with departmental access scoping.
PermissionIT AdminDepartment HeadManagerEmployeeContractor
app.access
documents.read_all
documents.read_deptdept-scoped
documents.create
documents.share_external
users.readdept-scoped
reports.rundept-scoped
settings.modify
"Dept-scoped" indicates a permission that requires ABAC layering on top of the role; the role grants access only within the user's department, evaluated at runtime against the resource's department attribute.
Export format referenceThe matrix you build in Rolemat exports to three formats. Examples below for the SaaS template above.
Markdown (paste-ready for GitHub/wiki)| Permission | Owner | Admin | Member | Viewer |
|---|---|---|---|---|
| account.read | ✓ | ✓ | ✓ | ✓ |
| account.update | ✓ | ✓ | | |
| billing.read | ✓ | ✓ | | |
...
CSV (paste-ready for spreadsheets)Permission,Owner,Admin,Member,Viewer
account.read,1,1,1,1
account.update,1,1,0,0
billing.read,1,1,0,0
billing.update,1,0,0,0
JSON (paste-ready for code){
  "roles": ["Owner", "Admin", "Member", "Viewer"],
  "permissions": ["account.read", "account.update", "billing.read", "billing.update"],
  "matrix": {
    "account.read":   { "Owner": true, "Admin": true,  "Member": true,  "Viewer": true  },
    "account.update": { "Owner": true, "Admin": true,  "Member": false, "Viewer": false },
    "billing.read":   { "Owner": true, "Admin": true,  "Member": false, "Viewer": false },
    "billing.update": { "Owner": true, "Admin": false, "Member": false, "Viewer": false }
  }
}
The JSON shape is the most useful starting point for code: most authorization libraries accept a similar matrix as input or can be wrapped around one.
NIST RBAC reference (formal model)For projects that need to align with the NIST INCITS 359-2004 RBAC standard:
LevelWhat's addedWhen to use
RBAC₀ (Core)Users, roles, permissions, sessionsMost applications stop here
RBAC₁ (Hierarchical)Role inheritance (Manager inherits from Employee)When roles compose naturally; reduces matrix maintenance
RBAC₂ (Constrained)Separation-of-duty constraints (no user can be both Approver and Requestor)Compliance-driven environments (SOX, healthcare)
RBAC₃ (Symmetric)RBAC₁ + RBAC₂ combinedHighly regulated systems
Most application-level RBAC implementations operate at RBAC₀ or RBAC₁. Higher levels are typically enforced by enterprise identity systems (Okta, Azure AD) rather than application code.
Role explosion: when to escalate beyond RBACWatch for these signals that pure RBAC is breaking down:
You have more than ~30 roles for a single application
Role names start including conditions: Engineer-EU, Engineer-US, Engineer-EU-Admin
You're cloning roles to express scope: Manager-Sales, Manager-Marketing, Manager-Engineering
Permission grants involve "if" clauses that aren't in the matrix itself
When 2+ of these are true, layer ABAC (attributes for region, department, scope) on top of RBAC, or switch to a policy engine (OPA/Rego, Cedar, Permify).
Related conceptsPrinciple of least privilege. Each role should have the minimum permissions needed. Default to deny; grant explicitly. Audit role assignments quarterly.
Separation of duties. No single role should both initiate and approve sensitive actions (financial transfers, code deploys). Often expressed as a constraint across two roles rather than within one.
Time-bound roles. Some compliance regimes (PCI-DSS, HIPAA) require certain elevated permissions to be granted only for the duration of a specific task. PAM (Privileged Access Management) tools handle this.
Audit logging. Every permission check should be logged for sensitive resources. The audit log is often consulted more than the matrix itself.
Read more on /learn

If your access decisions need...	Use
To depend only on the user's role(s)	RBAC (Role-Based)
To depend on attributes of the user, resource, or environment (department, time of day, IP range)	ABAC (Attribute-Based)
To be expressed as policies in a high-level language (Rego, Cedar) and evaluated at runtime	PBAC (Policy-Based)
To depend on the user's relationship to the resource (owner, collaborator, viewer)	ReBAC (Relationship-Based, e.g., Google Zanzibar)
To combine multiple of the above	Hybrid; most production systems are RBAC + ABAC

Verb	Meaning	Common alternatives
read	View resource content	view, get, list
create	Add new resource	add, insert, post
update	Modify existing resource	edit, patch, put, modify
delete	Remove resource	remove, destroy
list	Enumerate resources	index, query
share	Grant access to others	invite, add_collaborator
transfer	Change ownership	assign, reassign
approve	Authorize a workflow step	sign_off, validate
export	Extract data outside the system	download, extract
audit	View access logs / history	view_audit_log, inspect
admin	Full control of the resource	manage, owner

Permission	Owner	Admin	Member	Viewer
account.read
account.update
billing.read
billing.update
users.invite
users.remove
data.read
data.write

Permission	Author	Contributor
posts.create
posts.edit_own
posts.edit_others
posts.publish
posts.delete	own only	own only
comments.moderate
media.upload
users.manage
themes.manage
comments.read

Permission	Owner	Manager	Customer Service	Fulfillment
products.create
products.edit
products.delete
orders.read
orders.update_status
orders.refund
orders.cancel
customers.read
customers.edit
inventory.read
inventory.adjust
reports.financial

Permission	Manager	Contractor
app.access
documents.read_all
documents.read_dept		dept-scoped
documents.create
documents.share_external
users.read	dept-scoped
reports.run	dept-scoped
settings.modify

Level	What's added	When to use
RBAC₀ (Core)	Users, roles, permissions, sessions	Most applications stop here
RBAC₁ (Hierarchical)	Role inheritance (Manager inherits from Employee)	When roles compose naturally; reduces matrix maintenance
RBAC₂ (Constrained)	Separation-of-duty constraints (no user can be both Approver and Requestor)	Compliance-driven environments (SOX, healthcare)
RBAC₃ (Symmetric)	RBAC₁ + RBAC₂ combined	Highly regulated systems

Define your access matrixin under 60 seconds.

RBAC reference: starter templates, model comparison, permission verbs, export formats

Quick-decision grid: RBAC vs ABAC vs PBAC

Standard permission verbs (CRUD + extensions)

Template 1: SaaS B2B app (4 roles × 8 permissions)

Template 2: Content management system (5 roles × 10 permissions)

Template 3: E-commerce platform (4 roles × 12 permissions)

Template 4: Internal corporate tool (5 roles × 8 permissions)

Export format reference

Markdown (paste-ready for GitHub/wiki)

CSV (paste-ready for spreadsheets)

JSON (paste-ready for code)

NIST RBAC reference (formal model)

Role explosion: when to escalate beyond RBAC

Related concepts

Define your access matrix
in under 60 seconds.