Choose the Right Excel Format for Files and Data

Use .xlsx for an ordinary Excel workbook; use cell formats to control how its values appear. Choose .xlsm if the working workbook needs VBA macros, .xls only when a receiving system requires the older format, and .csv for a single flat table. File formats determine what a saved file can contain. Cell formats determine how values display; they do not change the underlying values used in calculations.

For public sharing, make both decisions deliberately. Keep the working workbook, prepare a separate reviewed release copy, and check the exported or published table rather than assuming its appearance in Excel will carry over.

Select what the file must retain and whether it is for publication; the recommendation updates immediately.

Choose the File Format That Retains What You Need

Format	Best Fit	Limitation
.xlsx	Ordinary workbook	Cannot store VBA code
.xlsm	Workbook with VBA macros	Review a separate publishing copy
.xls	Excel 97–2003 compatibility	Use only when required
.csv	Single flat table	Active sheet only; no workbook formatting

Microsoft documents these Excel and text file formats. CSV is not an Excel workbook format, even though Excel can open and save it.

XLSX Is the Default for an Ordinary Workbook

Choose .xlsx when you need an ordinary workbook and do not need VBA macro code. It lets you keep the working file as a workbook rather than reducing it to a text table.

That is a different requirement from publishing records. A workbook can serve as the place where you maintain and review data, while a separate release file contains only the table readers should see. You do not need to replace your working workbook just because the publication workflow uses CSV.

If someone asks for an “Excel format” without specifying an extension, clarify whether they need a workbook or merely a table Excel can open. An .xlsx file and a .csv file can both be useful to that person, but they are not interchangeable deliverables.

XLSM Keeps VBA in the Working File

Use .xlsm when the workbook needs VBA macros. Saving that working file as .xlsx is not a way to retain its VBA code.

For publication, separate the automation from the public data. Review the table produced by the workbook, then create a data-only release copy in a format accepted by the publishing destination. The fact that a macro helped prepare the records does not mean readers need the macro-enabled workbook.

Keep the working .xlsm file separately. A public release should be an intentional selection of approved data, not simply the working file with a few sheets hidden.

XLS Is for a Specific Compatibility Requirement

Use .xls when the recipient requires the older Excel 97–2003 format. Do not choose it merely because the filename looks familiar or because the destination says it accepts Excel files.

Ask which extension the receiving system requires, and check the saved copy in that workflow. Compatibility with one accepted file type does not establish that every Excel file type is supported.

CSV Is for One Flat Table

Choose .csv when the deliverable is a single table of records rather than a workbook. Excel saves only the active sheet to CSV, and workbook formatting is lost.

Select the intended release sheet before exporting. If the workbook contains several tables, one CSV export does not deliver them all. Keep the original workbook so that the text export does not become your only working copy.

CSV also removes the visual cues that may have made the worksheet understandable. A status expressed only by a fill color needs a text value; a currency amount needs a clear unit in its header or documentation. For a fuller comparison, see CSV vs XLSX: which format should you use?.

Make Each Column’s Meaning Explicit

A publishable table needs one header row, one observation per row and one field per column. Avoid merged headings, blank separator rows and totals mixed into the records. Those features may help someone read a worksheet visually, but they blur the structure of the table being shared.

The following illustrative dataset shows the intended worksheet display. The two tables below describe the same records, joined by record_id; they are split here to keep the examples readable on a phone.

record_id	observation_date	status
00123	2026-09-30	Reviewed
00124	2026-10-01	Pending

record_id	amount_usd	completion_rate
00123	1250.50	12.5%
00124	980.00	80.0%

In the actual worksheet, these fields belong in one table. Put units in headers or accompanying documentation rather than requiring readers to infer them from symbols or formatting.

Store Identifiers as Text Before Entry or Import

record_id is a label, not a quantity to calculate with. Store it as Text so that 00123 and 00124 retain their leading zeros.

Set identifier columns to Text before entering data. For imports, explicitly treat those columns as text instead of relying on automatic conversion. Applying Text format afterward does not recover lost digits or change existing numbers into text.

Excel has only 15 significant digits of numeric precision. That makes numeric storage unsuitable for long identifiers whose every digit matters. Microsoft recommends text handling for leading zeros and long identifiers.

A display that looks correct is not enough evidence that the identifier survived. Check the released value against the source. If digits or zeros were already lost during entry or import, return to the original data rather than trying to repair the identifier with appearance alone.

Use an Unambiguous Date Display

Format observation_date as a Date and use a year-month-day display, as shown by 2026-09-30 and 2026-10-01. Then verify how those dates appear in the exported or published data.

Keep the field’s meaning clear as well as its appearance. An observation date is not automatically a publication date or a reporting-period end. Name the column for the event it records, and explain the reporting period alongside the dataset where needed.

The worksheet display is only one checkpoint. The release file and the public page must preserve an interpretation readers can understand without opening the original workbook.

Separate Amounts From Their Units

Format amount_usd as a Number with two decimal places. In the example, that produces 1250.50 and 980.00. The header identifies the currency without requiring a dollar sign in every value.

Showing two decimal places does not round the underlying data. If the release requires rounded values, treat that as a separate data decision and verify the result. A cell format alone changes what readers see in Excel, not what calculations use.

Retain a clear unit when exporting. A bare column called amount leaves readers dependent on information outside the table; amount_usd carries that meaning into a flat file.

Distinguish Percentages From Proportions

Format completion_rate as Percentage with one decimal place. The underlying values for the illustrative records are 0.125 and 0.8, displayed as 12.5% and 80.0%.

Excel’s Percentage format multiplies the existing value by 100 for display. An existing value of 0.125 therefore appears as 12.5%, while an existing value of 12.5 appears as 1250%. Applying a percentage format is not a correction for data stored on the wrong scale.

Check the scale before formatting and again after publication. If exporting a raw proportion, use a header such as completion_proportion and document that 0.125 means 12.5%. Do not leave readers to decide whether a bare number is a proportion or a percentage.

Number, Currency, Date, Percentage and Text are among Microsoft’s available number formats.

Store Status in a Field, Not Only a Color

Store Reviewed and Pending as text in the status column. Color can supplement those values in the working workbook, but it should not be their only representation.

An explicit status survives the loss of workbook formatting and gives readers a field they can interpret or filter. Keep the wording consistent across records so that the published table does not split the same status across different labels.

Apply Cell Formats Without Mistaking Them for Data Changes

In desktop Excel:

1. Select the cells or column.
2. Open Format Cells with Ctrl+1 on Windows or Command+1 on Mac.
3. Choose the Number tab, then the appropriate category and options.
4. Check representative values, including blanks, negative amounts and unusually large numbers.

Microsoft’s formatting instructions explain the platform controls and the distinction between display and stored value.

Apply formats by column meaning, not by whichever appearance makes a particular cell look tidy. An identifier column should remain text even if its values contain only digits. A percentage column needs a consistent underlying scale even if individual values happen to look plausible.

If a value looks wrong after formatting, inspect the underlying value before changing the format again. The issue may be a percentage scale, an identifier converted to a number, or data that needs correction at its source. Cosmetic changes can conceal those problems without fixing them.

Review the Release File Before Publishing

Create a separate file containing only the reviewed public table. Exclude sensitive information entirely; hiding rows, columns or sheets is not a publication safeguard.

Compare the release file’s row count and key totals with the approved source. Make sure the comparison covers the intended records, without accidentally including a worksheet total as another observation. The draft provides no expected row count or total for a real dataset; those checks must use your approved source.

Check identifiers against their original values, including leading zeros and all digits. Confirm the date convention and percentage scale. For CSV, inspect the raw text as well as importing it with explicit column types: reopening through automatic conversion is not an independent check that the original text survived unchanged. See the focused guide to Excel dates in CSV exports.

Record the source, reporting period, units and meaning of missing values alongside the dataset. A blank should not silently become a zero or acquire a meaning the source does not support. If the meaning is unknown, say so rather than supplying an explanation that was not documented.

Verify the Actual Published Table

TablePage accepts CSV, TSV, XLSX and XLS and turns an upload into a public dataset page with a shareable link and filterable table. That supported-format list does not include XLSM; keep the macro-enabled working file separate from the reviewed upload.

After publishing, inspect the actual page. Verify headers, dates, identifiers and numeric values rather than assuming Excel’s display formatting will carry over. In the illustrative records, that means checking that 00123 still has its zeros, that the observation date is understandable, and that the completion value has the intended scale.

Also check that status is available as text and currency is identifiable from the header or documentation. A successful upload establishes that the file was accepted, not that every field communicates the intended meaning. Share the page only after the published records match the reviewed release.