Does SharePoint SPFx support pre/post-processing files on upload and download?

I think Microsoft has a built-in way to do this. It's called Purview and I believe that you can configure it to encrypt files automatically during upload and decrypt them during download?

Hi,

If you are using SharePoint Online’s modern document library, SPFx supports building your own upload/download experience, but it does not provide a documented, supported hook for transforming file contents within the built-in Upload, drag-and-drop, or Download operations.

A ListView Command Set can launch your custom action through onExecute(). List-view state-change events are not before-upload events. Also, onListViewUpdated() is deprecated; Microsoft now recommends context.listView.listViewStateChangedEvent for observing list-view state changes.

For your requirements, I would consider the following design:

1/ Process the XML before uploading through your own interface.

Your custom command can open a file picker or a dialog containing your own drag-and-drop area. Your code can then process the XML and upload the transformed file through an API.

This supports drag-and-drop within your component, but does not intercept SharePoint’s native drop area. I would avoid attaching handlers to SharePoint’s internal page elements: Microsoft explicitly states that the page DOM is not an API and that dependencies on its structure can break.

2/ Use Power Automate or webhooks only if processing after storage is acceptable.

You do not need another SPFx extension for this. A flow or backend service can detect a new file, retrieve its contents, process it, and save an updated copy.

However, SharePoint webhooks are asynchronous, and Power Automate’s file-created trigger runs after the file exists. Therefore, neither approach guarantees encryption before the original XML reaches SharePoint. If versioning is enabled, replacing the file may also leave the original content in an earlier version.

If overwrites of existing files must be processed too, a creation-only trigger is insufficient. An update-aware implementation also needs to prevent its own changes from repeatedly triggering processing.

3/ Provide a custom download/export action.

That action can retrieve the stored XML, perform the authorized decryption, and generate the required output. It will apply only to downloads made through your custom route; it will not transform downloads made through SharePoint’s built-in Download action or other clients.

If processing must be mandatory, custom buttons alone are insufficient. My recommendation would be a controlled backend service that validates requests and processes the files, with permissions preventing users from uploading directly to the destination library. The backend would need its own appropriately scoped access; the SPFx interface would call that service. Hiding the standard Upload button would not enforce this requirement.

Finally, when you say “the file is saved with the decrypted blob stripped out,” do you mean the downloaded copy or the original stored in SharePoint? Updating the stored original would be a separate operation requiring concurrency and failure handling.

Microsoft references:

• BaseListViewCommandSet class
• Overview of SharePoint Framework Extensions
• Overview of SharePoint webhooks
• SharePoint connector
• View the version history of an item or file in a list or library