Short definition
An attachment in Jira is a file uploaded to an issue - screenshot, log file, document, video. Attachments are stored alongside the issue and visible to anyone who can see the issue itself. Admins control which file types are allowed and how large files can be. Attachments are governed by the issue's permission scheme and don't have their own access controls.
How Jira stores attachments
On Jira Data Center, attachments live in a directory on the filesystem - usually
$JIRA_HOME/data/attachments, organised by project and issue key. On Jira Cloud, they’re stored in
Atlassian’s managed object store, encrypted at rest, and served through signed URLs.
Either way, the metadata (filename, MIME type, uploader, upload date, size) lives in the Jira database alongside the issue. Removing an attachment from the UI removes both the file (or storage object) and the metadata row.
Attachment permissions
This is the part most teams get wrong: attachments don’t have per-file permissions. They inherit the permission scheme of the issue they’re attached to. If someone can see the issue, they can download every attachment on it. There is no built-in way to mark a specific attachment as restricted while making the rest visible.
In practice this means sensitive documents (security findings, customer data, internal financials) shouldn’t be attached to issues that need broad visibility. Common patterns to work around the limitation:
- Move sensitive issues to a project with a tighter permission scheme. Loses cross-team visibility.
- Link to an external system (Confluence, SharePoint) instead of attaching. Loses single-source-of-truth.
- Use Document Vault, which adds per-attachment access control and encryption-at-rest while keeping the attachment visible inside the issue UI for users who do have access.
Inline attachments and the rich-text editor
Pasting an image directly into a comment or description uploads it as an attachment automatically. This is the most common way attachments end up on issues - and the most common way sensitive content (screenshots of customer dashboards, log fragments containing tokens) ends up in places it shouldn’t. Editor settings can disable paste-to-attach for sensitive projects.
Attachment limits
Default size limit on Data Center is 10 MB; Cloud limits depend on plan. Admins can raise the limit, but very large attachments slow issue load times and bloat backups. Many teams cap attachments at 25 MB and push larger files to an artefact store, linking from the issue.
See also (Redmoon products)
- Document Vault for Jira - Encrypt-at-rest attachments on Jira Data Center, with per-attachment access control beyond what the issue's permission scheme provides.
- Document Vault Cloud - The Cloud equivalent - encrypted, access-controlled attachments stored separately from Jira's default attachment store.
Common questions
What is an attachment in Jira?
An attachment is a file uploaded to an issue - screenshot, log file, document, video. Attachments are stored alongside the issue and visible to anyone who can see the issue itself. Admins control which file types are allowed and how large files can be. Attachments are governed by the issue's permission scheme and don't have their own access controls.
Who can see Jira attachments?
Anyone who can view the issue can see and download every attachment on it. There's no per-attachment permission in vanilla Jira - attachments inherit the issue's visibility. If sensitive attachments need to be visible to fewer people than the issue itself, Jira's default model can't enforce that without a third-party app like Document Vault.
What file types can be attached to a Jira issue?
By default Jira accepts almost any file type. Admins can restrict via the attachment settings (Settings -> System -> Attachments) and via WAF rules at the network layer. The default size limit is 10 MB on Data Center (configurable) and varies by Cloud plan.
Can Jira attachments be encrypted at rest?
Cloud encrypts attachments at rest by default. Data Center doesn't - attachments sit on the file system in plain form, readable by anyone with shell access to the server. For Data Center deployments that need encryption at rest plus per-attachment access control, Document Vault is the standard solution.