Python vs Office Scripts for Excel Automation
Microsoft's answer to "VBA does not work in the browser" is Office Scripts: small TypeScript programs that live in OneDrive or SharePoint, run against a workbook in Excel for the web or the desktop app, can be recorded with an action recorder, and can be triggered from Power Automate. For many teams on Microsoft 365, Office Scripts are the obvious tool for automating a workbook. Python is the other obvious tool — the language most data work already happens in. They overlap, but they are built for different jobs: Office Scripts manipulate a workbook from inside Excel, while Python processes data and files from outside it. This page puts them side by side with the same task written in both, compares where they run, what they can reach, how they are scheduled, tested and shared, and suggests when to use each and when to combine them. It belongs to Choosing a Python Excel Library.
The two tools in one paragraph each
Office Scripts are TypeScript files (.osts) stored in the user's OneDrive or a SharePoint site. They run inside Excel — on the web, and in the Windows and Mac desktop apps for Microsoft 365 business and education accounts — and act on the workbook that is open, through an object model similar in spirit to VBA's. The Automate tab has a recorder that writes a script from your clicks. Scripts can be shared with everyone who can edit the workbook, added as buttons, and run from Power Automate flows on a schedule or trigger.
Python runs wherever Python runs — a laptop, a server, a container, a scheduled job in the cloud — and works with Excel files, usually without Excel at all: pandas and openpyxl read and write .xlsx, and the Microsoft Graph API edits workbooks stored in OneDrive or SharePoint. It brings the whole Python ecosystem: databases, APIs, statistics, machine learning, PDFs, email. (Python in Excel, which runs Python inside a cell in Microsoft's cloud, is a third option with its own trade-offs; see Using Python in Excel.)
The same task in both
A typical small job: in the Invoices sheet, highlight every invoice over 1,000 and add a total below the amounts. As an Office Script:
function main(workbook: ExcelScript.Workbook) {
const sheet = workbook.getWorksheet("Invoices");
const used = sheet.getUsedRange();
const values = used.getValues();
for (let r = 1; r < values.length; r++) {
if ((values[r][2] as number) > 1000) {
used.getCell(r, 0).getEntireRow().getIntersection(used).getFormat().getFill().setColor("#FFEB9C");
}
}
const totalRow = values.length;
sheet.getCell(totalRow, 1).setValue("Total");
sheet.getCell(totalRow, 2).setFormula(`=SUM(C2:C${totalRow})`);
sheet.getCell(totalRow, 1).getEntireRow().getFormat().getFont().setBold(true);
}
And the same with Python and openpyxl, operating on the file:
from openpyxl import load_workbook
from openpyxl.styles import Font, PatternFill
wb = load_workbook("invoices.xlsx")
ws = wb["Invoices"]
highlight = PatternFill("solid", fgColor="FFEB9C")
for row in ws.iter_rows(min_row=2, max_row=ws.max_row):
if row[2].value > 1000:
for cell in row:
cell.fill = highlight
total_row = ws.max_row + 1
ws.cell(total_row, 2, "Total").font = Font(bold=True)
ws.cell(total_row, 3, f"=SUM(C2:C{total_row - 1})").font = Font(bold=True)
wb.save("invoices_marked.xlsx")
print("highlighted:", [r[0].value for r in ws.iter_rows(min_row=2, max_row=total_row - 1) if r[2].value > 1000])
The two are strikingly similar in length and shape. The differences are in where they act. The Office Script changes the live workbook that someone has open in Excel, and every co-author sees the result immediately; it has no file to load or save. The Python script reads a file and writes a file — which is perfect for a generated report or a nightly job, but for a workbook people are editing in OneDrive, Python would go through the Graph API instead (see Read and Write Excel Online Ranges with Microsoft Graph).
How they compare
| Office Scripts | Python | |
|---|---|---|
| Language | TypeScript (a subset; no npm packages) | Python with any package |
| Runs | inside Excel (web, Windows, Mac) | anywhere — laptop, server, cloud job |
| Acts on | the open workbook | files, databases, APIs; cloud workbooks via Graph |
| Needs Excel | yes | no (except xlwings / COM automation) |
| Recorder | yes, Action Recorder | no |
| Scheduling | Power Automate flows | cron, Task Scheduler, CI, cloud schedulers |
| External data | limited fetch, Power Automate connectors | anything Python can reach |
| Large data | slow above tens of thousands of cells | pandas/polars handle millions of rows |
| Testing, version control | limited; scripts live in OneDrive | normal: pytest, git, code review |
| Licensing | Microsoft 365 business or education | free; Microsoft 365 only for Graph access |
Two rows deserve emphasis. Data volume: an Office Script reads and writes cells through Excel's object model, and every call has overhead; scripts that touch large ranges should read them in one getValues() and write once, and even then they are not built for hundreds of thousands of rows. Python with pandas or polars processes such volumes in seconds. Reach: Office Scripts are deliberately sandboxed — they work on the workbook, with only limited fetch calls to the web, and runs from Power Automate have per-call time limits and daily caps. Pulling data from a database, an SFTP server or an internal API is routine in Python and awkward or impossible in an Office Script.
Scheduling and sharing
An Office Script on its own runs when someone clicks Run or a button in the workbook. To run on a schedule or when something happens — a file arrives, a form is submitted — it is called from a Power Automate flow with the Run script action, which can pass parameters in and receive a return value. That makes Office Scripts plus Power Automate a no-server automation stack inside Microsoft 365, managed by business users. The trade-off is that logic lives in two places (the flow and the script), and failures surface in the flow's run history rather than in your usual logging. Comparing Power Automate with Python on whole workflows is covered in Python vs Power Automate for Report Workflows.
A Python job is scheduled like any program — cron, systemd timers, Windows Task Scheduler, GitHub Actions, a cloud scheduler — and logs, alerts and retries are under your control. It needs somewhere to run and someone to maintain it, which is easy for a team with developers and a real cost for one without. Sharing a Python tool with Excel users means either giving them its output (a report in their inbox or SharePoint) or packaging it, for example as an executable or a small web app.
Testing, versioning and maintenance
Python code lives in a repository, goes through code review, and has unit tests that run on every change — the habits that keep a report correct for years. Office Scripts are files in OneDrive; they can be copied into a repository by hand, but there is no built-in testing framework, and the usual way to check a change is to run it on a copy of the workbook. For a three-line formatting script that is fine; for business-critical logic, it is a real argument for keeping the logic in Python and the Office Script thin. Office Scripts do have one maintenance advantage: they always match the workbook's own object model, so there is no file-format library that might not support a feature — charts, tables, PivotTables and slicers are all reachable through the API.
Combining them
The tools combine well along their natural boundary. A common pattern: a Python job prepares the data — querying a database, cleaning and aggregating with pandas — and writes the result into a table in a workbook on SharePoint through Microsoft Graph, or drops a file there; a Power Automate flow then runs an Office Script that refreshes PivotTables, applies formatting and timestamps the sheet for the people who work in it. Each tool does what it is best at: Python the heavy data work and integrations, the Office Script the in-workbook polish that needs Excel's own engine. Writing to an Excel Online table from Python is shown in Append Rows to an Excel Online Table with Microsoft Graph.
Common pitfalls
- Big data in an Office Script. Cell-by-cell loops over large ranges are slow; process data in Python.
- Business logic split across flow, script and workbook. Keep the logic in one place that can be tested.
- Python editing a file someone has open in OneDrive. Use the Graph API or let an Office Script make the change.
- Assuming Office Scripts are available everywhere. They need Microsoft 365 business or education accounts.
- Choosing by language preference alone. Choose by where the job runs and what it must reach.
Conclusion
Office Scripts and Python overlap but suit different jobs. Office Scripts are the natural choice for changing a shared workbook from inside Excel — user-triggered buttons, recorded steps, scheduled formatting through Power Automate — without servers or Python skills. Python is the choice for processing data from outside sources, handling large volumes, producing files and integrating with everything else, with proper testing and version control. For many teams the best answer is both: Python prepares the data and an Office Script finishes the workbook.
Frequently asked questions
What is the difference between Office Scripts and Python for Excel? Office Scripts are TypeScript programs that run inside Excel against the open workbook. Python runs outside Excel and works with files, databases and APIs, reaching cloud workbooks through the Microsoft Graph API.
Can Office Scripts run on a schedule? Yes, through Power Automate. A flow with a recurrence or another trigger calls the Run script action, which can pass parameters to the script and receive a result.
Can Office Scripts handle large datasets? They work through Excel's object model, which is slow for very large ranges. Read and write ranges in one call where possible, and use Python with pandas or polars for large data processing.
Should I replace VBA with Office Scripts or Python? Use Office Scripts for in-workbook automation that must work in Excel for the web and be run by users. Use Python for data processing, integrations and generated reports. Many teams use both.
Related
- Up one level: Choosing a Python Excel Library — picking tools for Excel work.
- Python vs VBA for Excel Automation — the desktop counterpart of this comparison.
- Translate Common VBA Macros to Python — moving existing macros.
- Run a Report When an Excel File Changes in OneDrive — a Python trigger for cloud workbooks.
More on choosing a library
- Comparisonxlwings vs pywin32 for Excel Automation
- Comparisonopenpyxl vs xlsxwriter vs pandas.ExcelWriter
- How-toChoose a Scheduler for Python Excel Reports
- ComparisonGoogle Sheets vs Excel Files for Python Automation
- How-toLightweight Python Excel Libraries Compared
- Comparisonopenpyxl vs pandas for Excel Automation