Power Query: Select Columns and Keep the Fields You Need

To select columns in Power Query for Excel, open the query in Power Query Editor, then choose Home > Manage Columns > Choose Columns and check the fields to keep. To keep a visible set quickly, select those column headers, right-click, and choose Remove Other Columns; Power Query records the selection as a repeatable step.

What selecting columns does

Selecting columns determines which fields continue through a query. It does not change the original worksheet or source file: Power Query applies the selection when the query is previewed or refreshed, and the resulting table contains only the selected fields. This is useful when a source has many columns but a report, model, or follow-up transformation needs only a few.

For example, an order export might contain OrderID, OrderDate, Customer, Region, Product, Quantity, UnitPrice, Tax, ShippingAddress, and InternalNote. A summary that needs only OrderID, OrderDate, Region, and Quantity can drop the other fields before loading. The smaller result is easier to inspect and maintain, and it avoids carrying irrelevant data into later steps.

In Power Query, selecting columns means keeping the chosen fields; removing columns means excluding chosen fields. Both approaches can produce the same result. Which one is clearer depends on the source: choose the fields you need when that set is short and intentional, or remove a few unwanted fields when nearly every column is useful.

Choose columns in the Excel interface

These steps apply to Excel for Microsoft 365 on Windows. Start by selecting a cell in the source table or opening the workbook that contains the query, then open the query in Power Query Editor. In Excel, the editor is commonly opened from Data > Queries & Connections by double-clicking the query. The exact route to create or open a query can vary with the source and Excel build.

In Power Query Editor, select Home > Manage Columns > Choose Columns.
In the dialog, clear the check boxes for fields you do not want, or use the available selection controls to reset the list and choose the required fields.
Select OK. The preview updates and an Applied Step is added to the query.
Check the preview, then select Home > Close & Load or Close & Load To, as appropriate for the workbook.

The dialog is convenient when a table has many fields because you can make the selection without scrolling across every column in the preview. If the needed columns are already visible and adjacent, you can select their headers directly. Use Ctrl-click on Windows to add or remove individual headers from a selection; then right-click a selected header and choose Remove Other Columns. For a contiguous range, select the first header, hold Shift, and select the last. Header selection works on column names, not on individual cell values.

Excel for Mac has Power Query features, but the editor’s available connectors and interface can differ by Excel version and update channel. If a ribbon command is not in the same place, look for the equivalent Choose Columns or Remove Other Columns command in the editor’s menus. Excel for the web does not provide the same full desktop editing experience in every scenario, so use Excel desktop when these instructions or a connector are unavailable.

Choose columns versus Remove Other Columns

Choose Columns opens a list of fields, which makes it a good choice when you want to review the full schema and deliberately keep a small subset. It is also easier to revisit if column names are similar or some fields are off-screen. Remove Other Columns is often faster when the desired headers are already visible: select the columns to retain, then remove everything else in one operation.

Removing only selected columns is different. If you right-click a column and choose Remove, Power Query removes that field while leaving the rest. This is efficient when there are just one or two unwanted columns in an otherwise useful table. The distinction matters: Remove Other Columns keeps the selected fields and discards the unselected ones; Remove discards the selected fields.

All three choices create transformation steps, rather than permanently editing the source. A later refresh re-applies those steps to the updated source. If a newly added source column should be included automatically, a fixed selection of named columns will not include it unless you update the query or use a dynamic selection approach.

What the M code looks like

Power Query stores transformations in the M language. A column-selection step is usually represented by the Table.SelectColumns function. For instance, if the preceding step is named Source, the step below keeps three fields:

Table.SelectColumns(Source, {"OrderID", "OrderDate", "Amount"})

The first argument is the table being transformed; the list in braces contains the column names to retain. In a full query, a step name may be written as #"Changed Type" when it contains a space. A formula bar expression could therefore look like = Table.SelectColumns(#"Changed Type", {"OrderID", "OrderDate", "Amount"}). The interface normally creates this code for you, so editing M is optional.

The order of names in the list determines the output column order. That can be useful when you want a stable, readable layout regardless of the order in the source. Column names must match the source names, including spaces and punctuation. If a requested name is absent, the default behavior is to raise an error rather than silently ignore the missing field.

For a query that should tolerate missing fields, the optional third argument can change that behavior. Table.SelectColumns(Source, {"OrderID", "Region"}, MissingField.Ignore) keeps the listed fields that exist and skips those that do not. MissingField.UseNull instead supplies a null-valued column for a listed field that is missing. These options are useful when files in a recurring import do not always have identical schemas, but they should be chosen intentionally: ignoring a missing field can conceal a change that deserves investigation.

Select columns dynamically

A fixed list is usually best when a report depends on known fields. Dynamic selection is helpful when the source schema changes in a predictable way, such as when you want every field whose name begins with Sales. One M expression can build a list from the names in the current table and then pass that list to Table.SelectColumns:

Table.SelectColumns(Source, List.Select(Table.ColumnNames(Source), each Text.StartsWith(_, "Sales")))

Here, Table.ColumnNames returns the current field names, List.Select keeps names that satisfy the condition, and Table.SelectColumns applies that list to the table. This can accommodate new matching fields without manually editing a fixed list. It also means the output can change as the source schema changes, so check whether downstream steps and reports can handle that variation.

Dynamic selection is not automatically safer. If a source renames a field so it no longer matches the pattern, that field disappears from the result. If it adds a similarly named field, the new field may enter the result unexpectedly. For a fixed report layout, explicit names are more predictable. For a changing set of columns, use a rule that is narrow enough to express the actual requirement and review the resulting preview after refresh.

When to select columns and how it affects performance

It is often sensible to remove irrelevant fields early, especially when a source contains wide tables or large text columns. A smaller table is simpler to inspect and can reduce the amount of data carried through later transformations. With some external sources, Power Query can fold the selection back to the source, meaning the source performs some of the work or returns fewer fields. Whether that happens depends on the connector, source, and steps in the query; it is not guaranteed.

For example, a database connector may be able to request only the chosen fields, while a worksheet or text-file source may need to read the file before applying the selection. Query folding is therefore a possible optimization, not a promise that selecting columns will always make refresh dramatically faster. If performance matters, inspect the query’s folding indicators or source-specific guidance, and avoid assuming that every transformation is pushed back to the source.

Do not remove a field just because it is absent from the final output if a later step still needs it. A column might be used to filter rows, join two tables, group records, calculate a custom field, or expand a nested table. A safe pattern is to keep every field required by later steps, perform those operations, and remove fields once they are no longer needed. If you select columns too early, later steps can fail with a missing-column error.

Common problems and how to fix them

A refresh reports that a column was not found: Check whether the source renamed the field, changed punctuation or spacing, or stopped including it. Update the selection list or use an appropriate missing-field option if variation is expected.
A later step fails after columns were removed: Review the Applied Steps list and identify any filter, merge, grouping, or custom-column step that uses the removed field. Move the selection later or retain that field until the dependent step is complete.
A new source column does not appear: A fixed selection keeps only the names explicitly listed. Edit the selection to include the new field, or use a carefully designed dynamic rule if new fields should be included automatically.
The output fields appear in an unexpected order: In the M expression, arrange the names in the list in the desired order. The selection list controls the output order.
The column is visible in the worksheet but not in the query: Confirm that the query’s source points to the expected table or file and that the column exists at the step where the selection occurs. Earlier transformations may have renamed, split, or removed it.

When troubleshooting, select each Applied Step in turn and inspect the preview. This helps locate the first step where a field disappears or changes name. It is usually more useful than changing the final step blindly, because the real cause may be an earlier rename or a source schema change.

Practical choices for common workflows

For a one-time cleanup of a wide import, use Choose Columns and retain the fields the workbook actually uses. For a simple export where nearly every field is relevant, remove the few unnecessary columns instead. If you are combining monthly files, make sure each file has the fields required by the selection; inconsistent headers are a common reason a refresh works for one file but fails for another.

For a report that must always have the same columns, use an explicit list and verify the names. For a process that intentionally accepts changing columns, use a dynamic rule and test it against representative source variations. Before loading, confirm that the output has the expected headers, order, and data types. Selecting columns does not set data types, validate values, or remove duplicate rows; those are separate transformations.

Frequently Asked Questions

How do I select multiple columns in Power Query?

Use Home > Manage Columns > Choose Columns to check several fields in the dialog. Alternatively, select multiple headers in the preview with Ctrl-click on Windows, then right-click and choose Remove Other Columns to keep only those fields.

What is the difference between Remove Columns and Remove Other Columns?

Remove Columns deletes the selected fields and keeps the rest. Remove Other Columns does the reverse: it keeps the selected fields and deletes all unselected fields. Choose Columns provides a dialog for specifying the fields to retain.

Does selecting columns change my original Excel data?

No. It changes the query’s result, not the source table or file. On refresh, Power Query reads the source again and applies the recorded selection step.

Can Power Query automatically include new columns?

Not when the query uses a fixed list of column names. To include fields added later, edit that list or use a dynamic M expression based on a naming rule. Dynamic selection can also include unwanted fields, so review the output after refresh.

Why does Power Query say a column does not exist?

The source may have changed the column name, or an earlier query step may have removed or renamed it. Check the source headers and inspect Applied Steps to find where the field first disappears. If missing fields are expected, consider MissingField.Ignore or MissingField.UseNull in the M expression.

Try it: the Date Difference Calculator: days, months, years and weekdays between two dates, with the DATEDIF formulas.

More in How-to basics

Sources: Function behaviour and menu paths: Microsoft Support documentation for Excel. Method & sources

Spotted an error in this guide? Let us know.