Early and Late Binding

Some of the examples on this site require early binding, but most use late binding.

Early Binding

Early binding means you are referencing object libraries at compile time, rather than run-time. Late binding means you are declaring your objects As Object or As Variant.

The "Theory"

Two steps are required to declare early bound objects:

  1. Set a reference to the object library manually by going to Tools » References in the VBA Editor, and
  2. Declare objects as their intended type instead of As Object or As Variant.

If you set references to object libraries and typecast your objects accordingly, you will have access to the properties and methods of that object during the code-writing phase, which is an immense benefit for anyone, even experienced programmers.

It makes writing code much easier because you can use the Intellisense feature to auto-complete code, which avoids many syntax errors and cuts down on time spent coding. It makes your code faster, since VBA makes memory associations at compile time rather than having to create them on the fly.

The "Practice"

To set a reference to an object library, open your favorite Office program and press Alt+F11 to access the VBA Editor, then Click Tools » References and select the appropriate library.

For Excel, choose "Microsoft Excel x.0 Object Library", or for Outlook choose "Microsoft Outlook x.0 Object Library".

The "x" stands for your version; Office 2000 is version 9, Office XP, version 10, Office 2003 is version 11, and Office 2007 is version 12. Office 2010 is version 14.

So if you were setting a reference to the Excel 2003 Object library, choose "Microsoft Excel 11.0 Object Library." This assumes that it is installed on the local computer. Here I am setting an early bound reference to the MSXML 6.0 Object Library:

Object Libraries

The benefits of late binding

At this point you might be asking, with all these benefits, why would anyone ever want to use late binding?

Well, there are several reasons.

  1. The code isn't really that much slower, if at all.
  2. You aren't hardcoding your Office version, so you don't need to worry about different versions being on whatever computer the code is running on. If I write:
  3. Dim objOL As Object
    Set objOL = CreateObject("Outlook.Application")

    On your computer that could mean Outlook 2000, on mine, Outlook 2003, on someone else's, Outlook 2010. This is perfect for code that is to be distributed (or posted on a blog) where many different configurations exist. As long as my method calls are supported by every version, I can distribute this code without worrying what version it will be used on.

  4. You don't need to worry about adding object references through the Tools » References interface. This is a manual process which is simply another thing to forget.

The benefit is seen when writing code for others: your co-workers, friends and others can use the code directly without having to set early bound references. Try explaining to a co-worker who has never even seen the VBA IDE how to set references. Do it just once and I guarantee you'll want to write late bound code.

But just because you give out late bound code, does not mean you have to write late bound code.

What I do now is add the object library reference, code my application early bound, then convert everything to late bound code before using it in a "real" application (or posting it on my blog). See Why I prefer late bound code and Take advantage of Intellisense when writing late bound code for details on just how to do that. That way I get the benefits of both early bound AND late bound code.


Here is an example to illustrate the difference when coding. Early bound object reference:

Dim objOL As Outlook.Application
Set objOL = CreateObject("Outlook.Application")

Late-bound object reference:

Dim objOL As Object
Set objOL = CreateObject("Outlook.Application")

It doesn't matter how you actually instantiate the object, it's the declaration that counts. You can use CreateObject (and GetObject) with an object declared as Outlook.Application. I do it this way so I can switch between early and late bound, I only have to change one line (the declaration).

Following best practice, I place all variable declarations at the beginning of each procedure. The code to declare an object and instantiate it are not always found together. So the changes (if any) all take place in one section of code, making it even easier to switch between early and late binding.

Unfortunately, misinformation about early and late binding continues to persist. Search for "createobject getobject late binding vba" and you'll see a myriad of differing uses. From what I have seen, many code samples either

  1. mistakenly state that GetObject and CreateObject are exclusively late binding functions, or
  2. only use GetObject and CreateObject when showing examples of late bound code, implying that they are only for use with late binding.

Here's an example of an article that gets it right: Early vs. Late Binding

My recommendation is to ALWAYS use GetObject and CreateObject, regardless of the binding method.


  1. If you declare an object As Object, it will always be late-bound no matter how you instantiate it.
  2. It is not the instantiation that determines binding, it is the declaration. CreateObject and GetObject are not exclusively late binding functions.
  3. To declare an object as early bound, you must set an object reference using Tools » References and then declaring natively-typed objects.
  4. Write your code early bound, then convert to late bound to take advantage of both systems.

Site last updated: August 20, 2014

learn excel dashboards