How to Convert an Excel UserForm to an Online App

TL;DR: Converting an Excel UserForm to an online app means rebuilding its three parts for the browser: the controls become HTML form fields, the VBA event code behind them becomes JavaScript and server-side logic, and the worksheet the form writes to becomes a database table. There is no automatic converter, because UserForms do not run in Excel for the web, in the mobile apps or in Office Scripts. A workbook built around UserForms typically converts in 3 to 6 weeks, and the result can be used by many people at once on any device.

If your workbook has a UserForm, somebody already designed an application: there are fields, rules, a save button and a place where records go. That makes it one of the clearer conversion jobs. This is how it is done.

Why Can a UserForm Not Simply Be Put Online?

A UserForm is a VBA object, and VBA runs only in desktop Excel. Open the same workbook in Excel for the web or on a phone and the sheets appear, but the form does not, and the button that should launch it does nothing. Office Scripts, the automation language Microsoft offers for Excel on the web, has no equivalent of a UserForm: the most a script can do is show a plain prompt for its input parameters. We track these gaps in what VBA still cannot do online.

So the form cannot be moved. It has to be rebuilt, and the rebuild only works if all three of its parts are carried across.

What Is a UserForm Actually Made Of?

1. The controls. Text boxes, combo boxes, option buttons, check boxes and command buttons, laid out at fixed positions on a gray dialog.

2. The event code. The procedures that run when the form opens, when a value changes and when a button is clicked. This is where lists get filled, entries get checked and the record gets saved.

3. The storage. The worksheet the form writes to, plus the ranges it reads from to fill its dropdowns. In a UserForm workbook, that sheet is the database.

Copying only the first part gives you a web page that looks like the form and does nothing. Most of the work, and nearly all of the risk, is in parts two and three.

How Does Each Part Convert?

Job	In the UserForm	In the online app
Layout	Controls at fixed positions in a fixed-size dialog	An HTML form that reflows for a desktop, tablet or phone
Filling dropdowns	UserForm_Initialize, RowSource or AddItem reading a sheet range	Options loaded from a database table that an admin can edit
Validation	If checks and a MsgBox when Save is clicked	Rules on each field, shown beside the field, then checked again on the server
Saving	Write to the next empty row	Insert a database record with a user and timestamp
Editing a record	Find the row, load it into the controls, overwrite it	Open the record by its ID and save the changes
Output	A macro fills a template sheet and prints it	A PDF or Excel export generated on demand

For the control-by-control detail, from ComboBox and ListBox to MultiPage and MsgBox, see the UserForm section of our VBA to JavaScript mapping reference.

A Worked Example: an Order Entry Form

Here is a small but typical UserForm: a customer, a product chosen from a list, a quantity, and a Save button that appends a row to an Orders sheet.

Private Sub UserForm_Initialize()
    cboProduct.List = Sheets("Products").Range("A2:A40").Value
End Sub

Private Sub cmdSave_Click()
    If Trim(txtCustomer.Value) = "" Then
        MsgBox "Customer is required"
        Exit Sub
    End If
    If Not IsNumeric(txtQty.Value) Then
        MsgBox "Quantity must be a number"
        Exit Sub
    End If

    Dim r As Long
    With Sheets("Orders")
        r = .Cells(.Rows.Count, 1).End(xlUp).Row + 1
        .Cells(r, 1).Value = txtCustomer.Value
        .Cells(r, 2).Value = cboProduct.Value
        .Cells(r, 3).Value = CDbl(txtQty.Value)
        .Cells(r, 4).Value = Now
    End With
    Unload Me
End Sub

The same form as a web page. The validation moves into the markup:

<form id="order-form">
  <label for="customer">Customer</label>
  <input id="customer" name="customer" required>

  <label for="product">Product</label>
  <select id="product" name="product" required>
    <option value="">Choose a product</option>
    <option>Standard panel</option>
    <option>Outdoor panel</option>
  </select>

  <label for="qty">Quantity</label>
  <input id="qty" name="qty" type="number" min="1" step="1" required>

  <button type="submit">Save order</button>
  <p id="form-message" role="status"></p>
</form>

And the Save button becomes a submit handler that sends the entry to the server:

const form = document.getElementById("order-form");
const message = document.getElementById("form-message");

form.addEventListener("submit", async (event) => {
  event.preventDefault();
  try {
    const response = await fetch("/orders", {
      method: "POST",
      body: new FormData(form),
    });
    if (!response.ok) throw new Error("Save failed");
    form.reset();
    message.textContent = "Order saved";
  } catch (error) {
    message.textContent = "Not saved. Check the entry and try again.";
  }
});

In the finished app the product options are rendered from the products table, which is the job UserForm_Initialize did.

Three things changed, and they are the same three in every UserForm conversion:

1. Validation is declared, not coded. required and type="number" replace the If blocks. The browser will not submit the form until they pass, and it points at the field to fix. The rules are not identical, though, and a conversion has to settle each difference on purpose. IsNumeric accepts 0, -3 and 2.5, so min="1" and step="1" are stricter than the macro ever was, and the macro never checked that a product was chosen. In the other direction, required accepts a value made only of spaces, which the Trim check rejected.
2. The server checks again. Browser rules can be bypassed, so the server trims each value and runs the same checks before anything is saved, which is what MDN's guide to form validation recommends for every web form. The UserForm never needed this because only trusted staff could open the workbook.
3. A record replaces a row. "Find the next empty row" is the line that breaks when two people save at the same moment. A database insert has no such race. It records when each row was saved automatically, and who saved it once users sign in.

What Changes for the People Using It?

• Nobody opens a file. They open a link, on a PC, a Mac, a tablet or a phone.
• Several people can enter data at once. There is no "file is locked for editing" and no merging of copies.
• Each person signs in. Staff can be limited to their own records while a manager sees everything.
• Errors show on the field itself. The browser points at the entry to fix, and a finished app adds checks as the user types, instead of a message box after clicking Save.

The page on converting Excel VBA to a web application goes deeper into that multi-user redesign, and the LED display quoting system shows the result for a sales team that used to copy a master workbook for every quote.

What Does Not Carry Over?

A few UserForm habits have no direct web equivalent and are redesigned instead:

• Chains of modal forms. A form that opens a second form that opens a third becomes a sequence of steps or pages.
• ActiveX and third-party controls. Add-on calendar and grid controls are replaced by native date pickers and HTML tables.
• File pickers and printing. Application.GetOpenFilename becomes a file upload, and printing to the default printer becomes a PDF the user can print or email.
• Editing the sheet by hand between entries. If staff fix rows directly on the data sheet, the app needs an edit screen for that, with a record of who changed what.

Are There Alternatives to a Custom Rebuild?

For a form that only collects rows and is used inside one organization, yes. Microsoft Forms and Power Apps can both stand in for a simple data-entry UserForm, with the limits we describe in five ways to convert Excel to a web form. They stop being enough when the form runs calculations, when the VBA behind it is more than a few lines, or when customers need more than a simple survey-style form.

How Long Does It Take and What Does It Cost?

UserForm workbooks sit in the heavier tier of VBA conversions: typically 3 to 6 weeks, with cost ranges set out on our VBA conversion page. What moves a project within that range is the number of forms, the amount of code behind each one, and how many reports the workbook produces. Every screen and every calculation is checked side by side against the original workbook before delivery.

The complete guide to converting Excel to a web application covers hosting, handover and pricing in full. Or send us the workbook with the macros left in: within 24 hours you'll get a free Conversion Blueprint that lists each UserForm, what it becomes, and a fixed price and timeline for the conversion.

Frequently Asked Questions

Can I use my Excel UserForm online without rebuilding it?

No. A UserForm is a VBA object, and VBA does not run in Excel for the web or in the Excel mobile apps. Opening the workbook in a browser shows the sheets, but the form never appears. To use the form online, its layout, the code behind it and the sheet it saves to have to be rebuilt as a web application.

Is there a tool that converts a VBA UserForm to HTML automatically?

Not one that produces a working app. The layout of a form is the easy part and could be copied by hand in an hour. The behavior lives in VBA event procedures and in the worksheet the form reads and writes, and those have to be understood and rewritten by a developer, then tested against the original with real inputs.

What happens to the data my UserForm saves to a worksheet?

The existing rows are imported into a database table, so nothing is lost. From then on each submission is saved as a database record with a timestamp and the user who entered it. The data can be exported back to Excel at any time, which keeps existing reports and pivot tables usable.

Can several people use the converted form at the same time?

Yes, and this is usually the main reason to convert. A UserForm writes to the next empty row of one workbook, so two people cannot safely use it at once. An online app saves each submission as its own database record, so there is no file to lock and no copies to merge afterwards.

How long does it take to convert a UserForm to a web app?

Workbooks built around UserForms typically take 3 to 6 weeks, because the forms, the VBA behind them and the saved data all have to be rebuilt and verified. The main drivers are the number of forms, the amount of code behind each one and how many reports the workbook produces. We quote a fixed price and timeline within 24 hours of seeing the file.