How Much VBA Actually Converts to Python?
We ran 383 real VBA files from public GitHub repos — 122,874 lines we didn't write — through our deterministic converter. 82.8% came out as parser-clean Python. Here's the honest, reproducible breakdown, including exactly what breaks.
The Headline Numbers
Every “VBA to Python converter” claims it works. Almost none show a number on code they didn't hand-pick. So we ran an honest test on a large, messy sample of real VBA.
383
Real VBA files
sampled from public GitHub repos
122,874
Lines of VBA
code we didn't write
82.8%
Parser-clean Python
317 of 383 files
90%+
Runtime-correct
on a separate curated suite (openpyxl)
The bar for “pass” is strict and objective: the converted file must parse cleanly under Python's own ast.parse(). No “looks about right.” If it isn't syntactically valid Python, it fails — the same check that runs on every conversion the tool produces.
Where It Converts Well — and Where It Doesn't
We tagged every file by what it mostly does. The pattern is clear: the closer a macro is to “read a spreadsheet, transform data, write it back,” the better it converts.
| Category | Pass rate | What's in it |
|---|---|---|
| Excel automation | 103 / 120 (85.8%) | Range/cell reads & writes, formatting, sheet operations |
| Business logic | 196 / 235 (83.4%) | Loops, conditionals, string/date math, algorithms |
| UI / forms | 18 / 28 (64.3%) | UserForms, MsgBox/InputBox, ActiveX controls |
UserForm-heavy and ActiveX code is the weak spot — by design, since there's no clean, deterministic Python equivalent for a drag-and-drop VBA form.
The Failures, Ranked
We don't hide the 66 files that failed. Here are the reasons a file didn't produce clean Python, most frequent first — and the honest takeaway is that almost none of it is everyday business VBA.
| Count | Cause | What it means |
|---|---|---|
| 40× | Advanced constructs in library code | Concentrated in a handful of VBA libraries (JSON serializer, QR-code generator, PNG byte manipulation) that lean on edge cases like ReDim of typed byte arrays and Like pattern matching. |
| 5× | VBA array literals | Array(...) used with multi-dimensional ranges where the shape is ambiguous. |
| 5× | 2D array indexing | Nested parentheses blur the line between an array index and a function call. |
| 4× | return / GoTo inside error handlers | Bare returns and jumps that don't map onto Python's try/except structure. |
| 2× | On Error into an attribute | "On Error" mapped onto a Python attribute assignment. |
| Tail | = vs == in assertions, escaped-quote strings | A long tail of one-off syntax edge cases. |
Read that list again: the biggest bucket is advanced language constructs inside general-purpose libraries that happen to be written in VBA — the hardest possible input. If your macro loops over rows, does arithmetic, formats cells, and writes results, you're squarely in the 83–86% zone.
Parser-Clean vs. Runtime-Correct
The 82.8% above is the floor: valid, parseable Python. On a separate curated suite that measures runtime equivalence — does the converted Python produce the same workbook as the original VBA when you actually run it — the tool hits 90%+ on the openpyxl target.
Parser-clean is necessary but not sufficient; runtime-correct is the real goal, and it's why every conversion is verified with ast.parse() before you ever see it.
Why Deterministic Beats “Ask an AI to Convert It”
An LLM will happily convert any VBA you give it — and sometimes silently invent code that looks right and does the wrong thing. Our converter is rule-based: the same VBA in always produces the same Python out, every run. That has three consequences that matter if you're going to trust the output:
It's verifiable
Every conversion is checked with ast.parse() before you see it. If something can't convert cleanly, you get the exact line and error — not a confident guess.
It's honest about limits
When a construct has no clean Python equivalent (GoTo, ReDim Preserve, On Error Resume Next), it's flagged with a note instead of a fabricated translation.
It's diff-able
Re-run it, get identical output. You can review changes like any other code — which is load-bearing for trust.
Every converted file also ships with a runtime safety net, so unmapped APIs warn at runtime instead of crashing — meaning even a partial conversion gives you a runnable baseline, not a pile of errors.
Methodology
383 .bas / .cls files were sampled from public GitHub repositories (122,874 lines total). Each was converted with the deterministic VBAtoPython engine and scored pass/fail via ast.parse() on the output. Category tags were assigned by primary function. Figures are as of July 2026 and reproducible — the converter is deterministic, so the same input always yields the same result.
FAQ
What percentage of VBA converts to Python?
On 383 real GitHub VBA files (122,874 lines), 82.8% produced parser-clean Python verified with ast.parse(). Business-logic and Excel macros scored 83–86%; most failures were advanced library code.
Which VBA converts best?
Excel automation (85.8%) and business logic (83.4%). UserForm and ActiveX code is weakest (64.3%) — GUI forms have no clean deterministic Python equivalent.
Why do some files fail?
Failures cluster in general-purpose libraries written in VBA (JSON parsers, QR-code generators, PNG manipulation) that rely on language edge cases. Everyday data-prep and reporting macros rarely hit these.
Related Guides
- What VBAtoPython Converts (and What It Doesn't) — The full capability breakdown behind these numbers.
- Complete Syntax Mapping Reference — Every VBA construct mapped to Python side-by-side.
- VBAtoPython vs. ChatGPT — Why deterministic conversion beats an LLM for code you need to trust.
- Convert VBA to Python: Complete Guide — The end-to-end walkthrough.
See Your Own Number
Paste a macro and get parser-verified Python back, with a flag on anything that needs a human eye — before you pay a cent.