Power Query cannot read Binary content from SharePoint Online files without file extension

[danielbighelini]

Subject: Power Query cannot read Binary content from SharePoint Online files without file extension

Products

• Microsoft Excel (Power Query)

• SharePoint Online

---

Issue Description

We identified an inconsistent behavior when accessing files stored in a SharePoint Online document library through the Power Query connectors SharePoint.Files() and SharePoint.Contents().

Files that have a file extension (for example, .xml) can be accessed normally through the Content (Binary) column.

However, files stored in the same document library, with the same content, permissions, and location, but without a file extension, return an error when attempting to access the Content column.

---

Expected Behavior

Power Query should allow reading the binary content of files stored in SharePoint Online regardless of whether the file name contains an extension, provided that:

• The item is recognized by SharePoint as a valid file.

• The file can be downloaded successfully through the SharePoint web interface.

• The user has sufficient permissions to access the file.

---

Observed Behavior

When accessing the Content field of a file without an extension, Power Query returns an error.

Example:

DataFormat.Error:
The input URL is invalid.
Provide a URL to the SharePoint file path up to the file name only (without any query or fragment).

Additional details:

ErrorCode: 10290

In some scenarios, Power Query also prompts for authentication when attempting to access the Binary content of extensionless files.

---

Reproduction Scenario

A SharePoint Online document library contains two files with identical content:

File 1:

TEST_FILE_NO_EXTENSION

File 2:

TEST_FILE_WITH_EXTENSION.xml

Both files are stored in the same folder and document library.

---

Reproduction Query Using SharePoint.Files()

let
    Source =
        SharePoint.Files(
            "https://<tenant>.sharepoint.com/sites/<site>",
            [ApiVersion = 15]
        ),

    TestFiles =
        Table.SelectRows(
            Source,
            each
                [Name] = "TEST_FILE_NO_EXTENSION"
                or
                [Name] = "TEST_FILE_WITH_EXTENSION.xml"
        )

in
    TestFiles

---

Validation Query – File With Extension

let
    Source =
        SharePoint.Files(
            "https://<tenant>.sharepoint.com/sites/<site>",
            [ApiVersion = 15]
        ),

    FileContent =
        Table.SelectRows(
            Source,
            each [Name] = "TEST_FILE_WITH_EXTENSION.xml"
        ){0}[Content],

    FileSize =
        Binary.Length(FileContent)

in
    FileSize

Result

The query returns the file size successfully.

---

Validation Query – File Without Extension

let
    Source =
        SharePoint.Files(
            "https://<tenant>.sharepoint.com/sites/<site>",
            [ApiVersion = 15]
        ),

    FileContent =
        Table.SelectRows(
            Source,
            each [Name] = "TEST_FILE_NO_EXTENSION"
        ){0}[Content],

    FileSize =
        Binary.Length(FileContent)

in
    FileSize

Result

The query fails with:

DataFormat.Error:
The input URL is invalid.
Provide a URL to the SharePoint file path up to the file name only (without any query or fragment).

ErrorCode: 10290

---

Validation Using SharePoint.Contents()

The same behavior is observed when using SharePoint.Contents() and navigating to the file through the document library hierarchy.

Files with extensions work correctly.

Files without extensions fail when the Binary content is accessed.

---

Additional Findings

The file without extension:

• Is recognized by SharePoint as a file.

• Can be downloaded successfully through the SharePoint web interface.

• Has a valid size.

• Exists in the same library and folder as the file with extension.

• Uses the same Content Type ID as the file with extension.

• Has identical permissions.

Metadata returned by Power Query:

File Without Extension

Content Type = null
Kind = null
Size = null
Name = TEST_FILE_NO_EXTENSION

File With Extension

Content Type = text/xml
Kind = XML File
Size = 6193
Name = TEST_FILE_WITH_EXTENSION.xml

---

Comparison with Folder.Files()

As an additional validation, the same files were copied to a local folder (including a OneDrive-synchronized SharePoint folder) and accessed using:

Folder.Files("C:\Test")

In this scenario:

• Files with extensions work correctly.

• Files without extensions also work correctly.

• The Content Binary column can be accessed successfully.

• Binary.Length() returns the expected value.

• The file contents can be processed normally.

This indicates that the issue is specific to the SharePoint Power Query connectors (SharePoint.Files() and SharePoint.Contents()) and is not related to the file content itself.

---

Business Impact

This behavior prevents the use of native SharePoint Power Query connectors to process files without extensions stored in SharePoint Online document libraries, even though:

• The files physically exist.

• SharePoint recognizes them as valid files.

• They can be downloaded normally through the web interface.

• The same files can be processed successfully using Folder.Files().

We would like Microsoft to confirm whether this behavior is:

• A known limitation of the SharePoint Power Query connectors.

• A product defect.

• A configuration-related issue within SharePoint Online.

If this is a known limitation, please provide any supported workaround or recommended approach for processing extensionless files stored in SharePoint Online through Power Query.

no error with extensionerror without extension

[v-hashadapu]

Hi @danielbighelini , Hope you're doing fine. Can you confirm if the problem is solved or still persists? Sharing your details will help others in the community.

[v-hashadapu]

Hi @danielbighelini , Thank you for reaching out to the Microsoft Community Forum.

We find the answer shared by @Zanqueta  is appropriate. Can you please confirm if the solution worked for you. It will help others with similar issues find the answer easily.

Thank you @Zanqueta  for your valuable response.

[Zanqueta · Accepted solution]

Hi @danielbighelini based on the repro you shared, I would classify this as either a SharePoint Power Query connector limitation or a connector defect, not a permissions or file-content issue.
The strongest evidence is this:

• The same user can download the extensionless file from SharePoint Online.
• The same file works through Folder.Files().
• The same content works when the file has .xml.
• The failure happens only when Power Query tries to evaluate the SharePoint connector’s [Content] binary.
• Power Query metadata is incomplete for the extensionless file: Content Type = null, Kind = null, Size = null.

The SharePoint Folder / SharePoint.Files connector normally returns a table of files with a [Content] column that contains binary values, so accessing [Content] should be the correct pattern. Similar “input URL is invalid” errors are known around SharePoint connector URL/path handling, especially when the connector builds or interprets file URLs incorrectly.

My suggestion is to consider this a connector-side issue with extensionless SharePoint files.
Power Query seems to rely on SharePoint file metadata and/or URL construction when resolving the [Content] binary. When the file has an extension, SharePoint/Power Query can infer metadata such as Content Type, Kind, and Size. When the file has no extension, those values are returned as null, and the connector then fails when resolving the binary stream.

This is also consistent with your Folder.Files() test. Folder.Files() reads directly from the file system, so it does not depend on the SharePoint connector’s interpretation of the file extension, content type, or SharePoint download URL.

If you control the files, the most reliable and supported workaround is to rename them with a real extension, for example: TEST_FILE_NO_EXTENSION.xml

Even if the upstream system does not require extensions, adding the extension makes the file easier for Power Query to classify and process. This is the safest option for scheduled refresh and long-term maintainability.