Skip to main content

Export Jira Issues to CSV/Excel: Common Problems & FAQ

· 10 min read
NGPilot
NGPilot

Exporting Jira issues is something every team eventually needs to do, whether for migration, reporting, compliance, or backup. Yet the process is rarely as straightforward as clicking a button. Jira's native CSV export works for small result sets, but teams quickly run into field mismatches, encoding errors, custom field headaches, timeout failures on large projects, and the question of what to do with attachments. This FAQ answers the most common problems teams encounter when exporting Jira issues to CSV or Excel and provides practical solutions for each one.

Why do CSV fields mismatch after importing Jira exports?

Field mismatches are the most frequent complaint when teams move Jira data into another system. The root cause is almost always a difference in column order, delimiter settings, or date formatting between what Jira produces and what the target application expects.

When Jira generates a CSV file, the columns appear in a fixed order determined by the fields visible in your issue navigator view. If the receiving tool expects columns in a different order, rows shift and data lands in the wrong place. Always verify that header rows are included in the export so the target system can map columns by name rather than position. Delimiters matter too: Jira uses commas by default, but some European locale settings in Excel interpret commas as decimal separators, causing the file to parse incorrectly. In those cases, switching to a semicolon delimiter or using an Excel (XLSX) export avoids the problem entirely.

Date formats are another common source of trouble. Jira can output dates in several formats depending on your instance settings. For maximum compatibility, use ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ) so that every downstream system interprets timestamps consistently regardless of locale.

Simple Bulk Issues Export gives you explicit control over which fields to include and their column order, so you can match the schema your target system expects without manual rearranging after the fact.

How do I handle special characters in Jira CSV exports?

Jira issues often contain special characters, especially in summary and description fields where users paste error messages, code snippets, or text with non-ASCII characters. If encoding is not handled correctly, these characters appear corrupted after import.

The solution is to ensure your CSV file uses UTF-8 encoding throughout the export and import pipeline. UTF-8 covers virtually every character in use and is the de facto standard for data interchange. Most modern tools default to UTF-8, but older versions of Microsoft Excel sometimes assume a Windows-specific code page (such as Windows-1252) when opening CSV files. To avoid this, open the file through Excel's "Data > From Text/CSV" wizard, which lets you explicitly select UTF-8 before loading.

Within the CSV itself, any field that contains a comma, double quote, or line break must be enclosed in double quotes per RFC 4180. If a field value itself contains double quotes, those quotes are escaped by doubling them (""). Most export tools handle this automatically, but it is worth spot-checking a few rows after export to confirm.

Simple Bulk Issues Export generates UTF-8 encoded files by default and properly quotes fields that contain commas, line breaks, and special characters, so descriptions and comments survive the round trip intact.

Can I export Jira custom fields to Excel or CSV?

Custom fields are where Jira data gets organization-specific. Every company configures its own set of custom fields for sprint names, story point estimates, business units, customer segments, and dozens of other domain-specific attributes. Exporting them correctly is critical for reporting and migration.

The challenge is that some export tools only include standard Jira fields by default and require explicit mapping to pull in custom fields. Even when custom fields are included, the export sometimes uses the human-readable display name (for example, "Story Points") instead of the raw field key (for example, customfield_10002). The display name can change between Jira instances or even between projects, but the field key is stable and unique, making it far more reliable when importing data into another system.

If you are migrating between two Jira instances, check whether the custom field keys match. If they differ, you will need a mapping table to translate old keys to new ones during import. For reporting purposes, the display name is usually fine as long as you know which field it refers to.

Simple Bulk Issues Export makes custom fields available in the field selection panel (marked with a "Custom" label), so you can include them alongside system fields. The "Select All" button includes all custom fields, or you can pick specific ones. The display name is used for column headers, giving you readable output for reports and downstream tools.

Why do large Jira exports time out?

Jira's built-in export functions are designed for interactive use and enforce limits on result set size. When you try to export thousands of issues at once, the request can exceed server timeouts or memory limits, resulting in an incomplete file or an error page.

The most effective workaround is to split your export into smaller batches. You can do this by scoping your JQL query to a specific date range (for example, created >= "2025-01-01" AND created <= "2025-03-31"), by project, or by issue type. Export each batch separately and combine the files afterward. This approach also makes it easier to retry a single batch if something goes wrong, rather than starting the entire export over.

Another strategy is to reduce the number of fields included in each export. Every additional column increases processing time and file size. Export only the fields you actually need, and omit verbose fields like description or comments unless they are required.

Simple Bulk Issues Export handles large exports up to 1,000 issues per run. For exports beyond that limit, split your query into smaller batches by date range or project. The app processes field selection and formatting so the downloaded file is ready to use in Excel, Google Sheets, or any reporting tool.

Can I include attachments when exporting Jira issues?

Attachments are a special case because CSV and Excel files are purely text-based formats. There is no standard way to embed binary files like images, PDFs, or documents inside a spreadsheet cell. This means attachments require a separate export step.

The recommended approach is a two-part process. First, export your issues to CSV or Excel with all the metadata you need. Then, use Simple Bulk Attachment Downloader to export all attachments in bulk, organized by issue key. The attachment downloader preserves the folder structure and file names, making it straightforward to match attachments back to their parent issues.

If you only need a reference to the attachments rather than the files themselves, include the attachment URL column in your issue export. This column contains a direct link to each attachment in Jira, which is useful for reports and dashboards where clickable references are sufficient.

For teams migrating to a new tool, the combination of a full issue export plus a separate attachment download gives you everything needed to reconstruct the issue history in the target system.

How do I automate recurring Jira issue exports?

Manual exports are fine for one-time tasks, but teams that run weekly status reports, monthly compliance audits, or continuous data synchronization need an automated workflow.

The starting point is a saved JQL filter. Define the exact query that captures the issues you need, save it with a descriptive name, and reuse it every time you export. This ensures consistency between runs and eliminates the risk of accidentally changing the scope.

For full automation, the Jira REST API accepts JQL queries and returns results in JSON format, which you can convert to CSV or load directly into a database. Wrap the API call in a script and schedule it with cron (on Linux/macOS), Jenkins, or a cloud automation tool like Zapier or AWS Lambda. Include error handling in your script so you are notified if the API returns an error or if the result set is unexpectedly empty.

Simple Bulk Issues Export works with any saved JQL filter loaded in Jira's issue navigator. Load your saved filter in the navigator, then open the export dialog to export the filtered results. This ensures you always export the same issue set without rewriting the query each time.

Jira export format comparison

Choosing between CSV and Excel (XLSX) depends on your use case. The table below compares the two formats across the features that matter most for Jira exports.

FeatureCSVExcel (XLSX)
File sizeSmall, plain textLarger, compressed XML
EncodingMust specify UTF-8 explicitlyUTF-8 by default
Maximum rowsNo hard limit (practical limit around 1 million for most editors)1,048,576 rows per sheet
Rich formattingNot supportedSupported (fonts, colors, conditional formatting)
Multi-sheetNot supportedSupported
Special charactersRequires proper quotingHandled natively
Date handlingLocale-dependent parsingStored as serialized datetime
Tool compatibilityUniversal (any text editor, database loader, script)Requires Excel or compatible application
Automation friendlinessEasy to generate and parse in scriptsRequires a library (openpyxl, Apache POI)
Cell size limitPractical limit around 32,767 characters32,767 characters per cell

If you need maximum compatibility and plan to import the data into a database, scripts, or a BI tool, CSV is the better choice. If you are producing reports for stakeholders who expect formatted spreadsheets with multiple tabs, Excel is worth the extra overhead.

Field mapping guide

When exporting Jira issues, it helps to know the standard field names Jira uses in export files. The table below maps common Jira fields to their export column names so you can verify your data after export or configure field selection before running one.

Jira fieldExport column nameNotes
Issue KeyIssue keyUnique identifier, format PROJECT-123
SummarySummaryIssue title
StatusStatusCurrent workflow status
Issue TypeIssue TypeBug, Story, Task, Epic, etc.
PriorityPriorityHighest, High, Medium, Low, Lowest
AssigneeAssigneeDisplay name of the assigned user
ReporterReporterDisplay name of the user who created the issue
Created DateCreatedISO 8601 timestamp
Updated DateUpdatedISO 8601 timestamp
Resolution DateResolution DateEmpty if unresolved
Due DateDue DateDate only, no time component
DescriptionDescriptionMay contain wiki markup or HTML
LabelsLabelsSemicolon-delimited in CSV
ComponentsComponentsSemicolon-delimited in CSV
Fix Version/sFix Version/sSemicolon-delimited if multiple
SprintSprintSprint name and ID
Story PointsStory PointsNumeric, stored as a custom field
Original EstimateOriginal EstimateDuration in seconds or formatted string
Time SpentTime SpentDuration in seconds or formatted string
Remaining EstimateRemaining EstimateDuration in seconds or formatted string
AttachmentsAttachmentsCount or semicolon-delimited file names
CommentCommentAll comments, may be multiline
Custom fieldscustomfield_NNNNN or display nameNaming depends on export tool settings

Custom fields deserve special attention. In Jira's API and database, each custom field has a unique key in the format customfield_ followed by a five-digit number. Some export tools use this key as the column header, while others use the display name configured in your instance. If you are automating imports or building a data pipeline, prefer the raw field key for stability. If you are sharing the file with business users, the display name is more readable.