Skip to main content

Python in Excel Alternatives in 2026

· 8 min read

There are now several materially different ways to run Python with Excel. Comparing them only by “supports Python” hides the choices that actually determine whether a workflow will work: where Python executes, how it reaches workbook data, what packages it can load, whether it can create worksheet functions, and what another user receives when the workbook is shared.

This review compares Microsoft Python in Excel, Boardflare Python for Excel, xlwings Lite, and Anaconda Code as of August 10, 2026. Because these products are changing quickly, treat this as a dated market snapshot and verify the linked official documentation before making a deployment decision.

Start with the execution model

Python + Excel

├── Microsoft-managed cloud runtime
│ └── Microsoft Python in Excel

├── Browser / WebAssembly add-in runtime
│ ├── Boardflare Python for Excel
│ ├── xlwings Lite
│ └── Anaconda Code

└── Local / external Python
├── xlwings desktop/server patterns
├── PyXLL
└── pandas/openpyxl/COM/scripts

The execution model affects far more than performance. It determines the security boundary, package environment, access to local files and web APIs, workbook integration model, deployment requirements, and how much of the runtime the organization must manage.

At-a-glance comparison

DimensionMicrosoft Python in ExcelBoardflare Python for Excelxlwings LiteAnaconda Code
Primary runtimeMicrosoft CloudBrowser / PyodideBrowser / PyodideBrowser/WASM environment
Primary code surfaceWorksheet PY cellsReactive marimo notebookScripts, custom functions, notebooksExcel code environment
Separate local Python installNoNoNo for LiteNo external desktop Python required for Code
Interactive notebook/app surfaceWorksheet-focusedMarimo Edit + Run modesNotebook + App ModeCode-oriented Excel environment
Worksheet custom-function modelNative PY calculation, not user-published Python UDFsBF.FUNCTION() plus focused Editor functionsNative custom functionsUDF support
Explicit application output registryPY cell resultBF.OUTPUT()Workflow-dependent workbook writes/UDFsWorkflow-dependent
Browser package constraintsMicrosoft-managed package setPyodide/WebAssemblyPyodide/WebAssemblyEnvironment/version dependent
Main design centerPython analysis in Excel gridReactive workbook applicationsxlwings-style automation/UDFs in browserPython/R coding inside Excel

The table intentionally omits pricing and fine-grained licensing. Those change too quickly to freeze into an article without frequent maintenance.

Microsoft Python in Excel

Microsoft's native Python feature uses the PY function and executes Python in a secure Microsoft Cloud runtime. Microsoft provides a managed set of libraries and integrates Python results directly into the Excel calculation surface.

Official documentation:

Strengths

  • native Microsoft experience inside the grid;
  • no separate Python environment for the user to maintain;
  • strong fit for pandas/statistical analysis that starts from workbook data;
  • managed security and package environment;
  • Python results can feed the surrounding workbook.

Tradeoffs

The same managed environment that simplifies deployment also imposes boundaries. Python is not running as an unrestricted local desktop process. External data access follows Microsoft's supported model, and arbitrary local packages, folders, operating-system automation, and general desktop integration are outside the core product design.

Best fit

Start here when the artifact is fundamentally an Excel workbook containing bounded Python analysis and the Microsoft-managed runtime fits the organization's platform, security, package, and licensing requirements.

Boardflare Python for Excel

Boardflare uses a stock marimo reactive notebook running through Pyodide in the Office add-in browser environment. Workbook data enters through explicit bf.inputs() declarations. The notebook can publish values/tables through BF.OUTPUT() and short callable Python functions through BF.FUNCTION().

Notebook source and startup preference are saved with the Excel workbook, and the same application has an author-oriented Edit presentation and an operator-oriented Run presentation.

Current product documentation: Python for Excel.

Strengths

  • application-level reactive notebook rather than isolated Python cells;
  • explicit workbook input and published-output contracts;
  • interactive application UI through marimo;
  • published worksheet functions;
  • source travels with the workbook;
  • no separate desktop Python installation for workbook users;
  • same application model can be demonstrated in the standalone Univer host.

Tradeoffs

Boardflare inherits browser/WebAssembly constraints. Some native Python packages and desktop/system integrations are not appropriate for Pyodide. User-authored web requests are also subject to browser security and CORS behavior.

Run mode is a presentation experience rather than a permissions or source-protection boundary, and recipients need the Boardflare add-in.

Best fit

Evaluate Boardflare when the deliverable is a reactive workbook application built by a technical author for other Excel users rather than a one-time analysis.

xlwings Lite

xlwings Lite has evolved substantially. Its current documentation covers custom functions, automation scripts, browser/Pyodide execution, notebooks, package installation, web API access, and an App Mode that hides the code editor and exposes scripts/functions to end users.

Official documentation:

Strengths

  • familiar xlwings-style workbook programming model;
  • browser runtime without requiring a normal desktop Python installation;
  • custom functions and scripts;
  • notebook workflow;
  • App Mode for end-user operation;
  • direct workbook-object-model style programming.

Tradeoffs

The most important difference from Boardflare is not a missing checkbox. It is the programming model. xlwings Lite is organized around xlwings workbook APIs, scripts, custom functions, and notebook execution, while Boardflare's notebook model emphasizes an explicit reactive workbook-input registry and explicit live output/function publication.

Teams choosing between them should prototype the real application rather than compare slogans such as “browser Python” or “app mode.”

Best fit

Evaluate xlwings Lite when you want xlwings-style automation and UDFs in a browser-based Excel add-in, particularly if the team already knows the xlwings API.

Anaconda Code

Anaconda Code runs Python or R directly within Excel's add-in environment. Current Anaconda documentation describes a workbook environment where users can write code, manage packages and Pyodide/WebR versions, reference worksheet data, and create custom functions. As of this review, Anaconda documents the feature under its legacy Excel application section and labels Code beta.

Official documentation:

Strengths

  • Python and R support;
  • environment/package control within the Excel experience;
  • worksheet references;
  • user-defined functions;
  • familiar Anaconda ecosystem positioning.

Tradeoffs

The product model is different from Boardflare's reactive author-to-operator application workflow and from Microsoft's managed PY calculation model. Its beta/legacy documentation status is also something organizations should verify immediately before adoption rather than infer from this article.

Best fit

Evaluate Anaconda Code when the priority is an Anaconda-oriented Python/R coding environment inside Excel with configurable packages and UDFs.

What about external or local Python?

The four products above are not substitutes for every Python/Excel workflow.

If the job needs:

  • local folder traversal;
  • PDF/email processing;
  • scheduled jobs;
  • database pipelines;
  • desktop application automation;
  • unsupported native packages;
  • large multi-workbook batch processing;

then an external Python environment may be the right answer. The workbook can remain the user-facing artifact without containing the whole runtime.

This distinction is visible in practitioner discussions: many successful “Python + Excel” automations use pandas, openpyxl, xlwings, COM, or scripts around Excel rather than Python executing in the workbook itself.

How to choose

Ask these questions in order:

1. What is the artifact?

  • A few Python calculations in a workbook?
  • A reusable custom function?
  • An interactive application another person operates?
  • A batch process that produces workbooks?

The artifact is more important than the language.

2. Where must the code run?

If the workflow needs local system access, a browser or cloud sandbox may be the wrong runtime before package choice even enters the discussion.

3. Who maintains the code?

A workbook sent to non-programmers has a different deployment problem from an analyst's personal notebook.

4. What package and network boundaries apply?

Browser/Pyodide environments support a large Python ecosystem, including many scientific packages, but not every native dependency. Microsoft's environment is separately managed. Test the actual package set and external services early.

5. How does the second user open it?

This is the question product comparisons often skip. Test save/reopen behavior, required add-ins/licenses, startup, calculation, network access, and what the recipient sees when something goes wrong.

Bottom line

A useful shorthand is:

  • Microsoft Python in Excel: Python analysis integrated directly into the Excel grid.
  • Boardflare: reactive Python workbook applications with a notebook authoring layer and operator-oriented Run experience.
  • xlwings Lite: browser-based xlwings automation, scripts, notebooks, and custom functions.
  • Anaconda Code: Python/R code and UDFs in an Anaconda-managed Excel add-in environment.
  • External Python: the right answer when the workflow is really system automation or a data pipeline that happens to produce or consume Excel files.

The category will keep moving. That is why this article is dated rather than maintained as permanent product documentation.