How to Put VBA Code in Excel

If you just need to put vba code in excel and move on, the boxed answer at the top is all you need. The rest of this page is for when you want to understand why it works in Excel, adapt it to a trickier version, or make it robust enough to hand to a colleague. We keep the opening short on purpose — the depth is here when you want it, not in your way when you don’t.

Exact answer

In Excel: Press Alt + F11, choose Insert ▸ Module, type Sub YourName() and press Enter — Excel adds End Sub, and everything you type between the two lines is the macro.

VBA macro: Create a Macro in Excel

Sub GreetUser()
    Dim ws As Worksheet
    Set ws = ActiveSheet
    ws.Range("A1").Value = "Hello from my first macro"
    ws.Range("A1").Font.Bold = True
    MsgBox "Macro finished — check cell A1.", vbInformation, "First Macro"
End Sub

The smallest complete macro worth running: a name, a worksheet reference, two actions, and a confirmation. Every macro you write later is this shape with a longer middle.

How to run this macro

  1. Press Alt + F11 to open the VBA editor.
  2. Insert > Module.
  3. Paste the code above.
  4. Press F5, or close the editor and run it from Developer > Macros.
  5. Save the file as .xlsm so the macro is kept.
Annotated stepsExcel
1

Press Alt + F11 to open the VBA editor.

2

Right-click your workbook in the Project Explorer and choose Insert ▸ Module — a standard module, not a sheet object.

3

Type Sub followed by a name with no spaces, then brackets, e.g. Sub GreetUser(), and press Enter; End Sub appears automatically.

4

Write the actions between the two lines, then press F5 to run and check the result.

5

Save as Excel Macro-Enabled Workbook (.xlsm) so the code survives closing the file.

Ctrl+CthenCtrl+Shift+V+Cthen+Ctrl+VPaste values · WindowsMac

What this does

There are two ways to get a macro into a workbook, and they suit different moments. Recording is the faster start: Developer ▸ Record Macro, name it, perform the steps in Excel, then Stop Recording, and Excel writes the VBA for you. The generated code is verbose and full of .Select and .Activate lines that mirror your mouse movements, but it is real, runnable VBA, and reading it is the quickest way to learn what an object model call looks like. Writing by hand is the second route and the one everything non-trivial ends up needing, because the recorder cannot express a loop, a condition, or a prompt. Both end in the same place: a Sub inside a standard module. The one structural rule to internalise is where code lives — a standard module (Insert ▸ Module) holds macros anyone can run, while code typed into a sheet object or ThisWorkbook is event code, scoped to that object and invisible in the Macros dialog. Keep the inputs visible and clearly labelled and the whole thing stays auditable — anyone who opens the file later, including you, can see at a glance exactly what feeds the result and change one assumption without hunting through the formula. Treat “put vba code in excel” as a small repeatable workflow rather than a one-off click you hope to remember next time. Use a small test block before the live file, so any surprise in the affected cells shows up while it is still harmless. When this is a ribbon command, the selection matters more than the button: confirm the range, apply the command, then spot-check the output before saving. That turns a workflow that saves repeating the same clicks every week into a method you can reuse, explain, and defend when the workbook leaves your screen.

A worked example

Create your first macro end to end. Press Alt + F11, right-click your workbook in the Project Explorer, and choose Insert ▸ Module. In the blank window type Sub GreetUser() and press Enter — the editor supplies End Sub on its own. Fill in the body so it matches the snippet above, then press F5. Cell A1 now reads "Hello from my first macro" in bold and a dialog confirms it finished. Switch back with Alt + F11 and the macro appears under Developer ▸ Macros as GreetUser, ready to run from the sheet. Save with Ctrl + S and choose Excel Macro-Enabled Workbook (.xlsm) when the format warning appears — accepting the default .xlsx would throw the code away. Creating the first macro is mostly about learning where code is allowed to live and which save format keeps it. Once those two facts are in place, every later macro is the same three moves — module, Sub, F5 — and the only thing that changes is what goes in the middle. If there is any chance you will reuse this, drop it into a small template tab right now: a labelled input area on the left and the formula beside it, checked once against the tool above. Next time the same question comes up, the answer is a single paste away instead of a rebuild from memory.

In Google Sheets

Google Sheets handles this almost identically to Excel. The formula syntax above is the same, and the menu lives under a slightly different label rather than a ribbon tab. Use the platform toggle at the top of the page to switch every keyboard shortcut between Windows and Mac, and expect at most cosmetic differences in naming. The aim was to get you unstuck fast and leave you a little more capable than a copy-paste would. The answer is at the top, the tool proves it, and the detail above shows why it holds — so the next time a colleague asks, you can answer without reaching for search. The short version of “put vba code in excel”: the answer is at the top of this page, the tool proves it on your own numbers, and the sections above explain why it holds so the next variation does not stump you. Excel rewards people who reference cells instead of typing values and who keep inputs separate from formulas, because that is what makes a result you can audit months later. Build it once, deliberately, with the live tool as a check, and you convert a one-off lookup into a reusable skill — which is the whole point of learning the why and not just the what.

Common mistakes

  • Saving as .xlsx at the end. Excel warns once, and if you click through it the whole module is discarded — the workbook reopens with no macros and no way to recover them.
  • Putting a general-purpose macro in a sheet object rather than a module. It still runs from F5 inside the editor, which hides the problem, but it never appears in Developer ▸ Macros and cannot be assigned to a button.
  • Naming a macro with a space, a leading digit, or a reserved word. VBA rejects Sub My Macro() outright; use MyMacro or My_Macro.
  • Keeping the recorder's .Select and .Activate lines. They make the macro slow and force it to depend on which sheet happens to be in front — Range("A1").Value = 1 does directly what Select-then-ActiveCell does in two fragile steps.
  • Skipping Option Explicit at the top of the module. Without it a mistyped variable name becomes a silent empty variable instead of a compile error, and the macro fails in a way that is genuinely hard to trace.

Frequently asked questions

Should I record a macro or write one?

Record when the job is a fixed sequence of clicks and you want to see the equivalent VBA. Write by hand as soon as it needs to repeat over rows, decide between cases, or ask the user anything — the recorder cannot produce loops or conditions.

Where exactly does the code go?

In a standard module: Alt + F11, then Insert ▸ Module. Macros in a sheet object or ThisWorkbook are event code, scoped to that object, and do not show up in the Macros dialog.

How do I make one macro available to every workbook?

Record any macro with "Store macro in: Personal Macro Workbook" selected. That creates PERSONAL.XLSB, which opens hidden with Excel, and anything you put in its modules is available in every file on that machine.

Why does my new macro not appear under Developer ▸ Macros?

Either it lives in a sheet object instead of a standard module, or it is declared Private, or it takes arguments — Sub Name(x As Long) is hidden from the dialog because Excel has no way to supply x.