At some point in almost every MS Access project, someone asks: “Can I store photos in here?” Whether it’s employee profile pictures, product images, document attachments, or company logos — the need to display visual content alongside your records is very common.
The short answer is yes, Access can handle images. But how you store them matters enormously — and choosing the wrong method can quietly cause problems that only show up later when your database has grown, slowed down, or become difficult to manage.
This guide, based on the Skill Header tutorial “What is Best to Store Images and Objects in MS Access,” walks through all three available methods, explains what each one does, and tells you which one you should actually use.
The Three Methods Access Offers
Access gives you three ways to work with images and file objects:
- OLE Object — the old approach, built into early versions of Access
- Attachment field — Microsoft’s newer built-in option, introduced in Access 2007
- File Path (Text field + Image control) — the recommended approach used by experienced developers
Let’s go through each one.
Method 1: OLE Object
OLE stands for Object Linking and Embedding. It’s the oldest method and has been in Access since the beginning. You create a field with the OLE Object data type, and Access stores the image or document directly inside the database file.
Sounds straightforward — but there are serious problems with this approach.
What actually happens under the hood
When you insert an image using OLE, Access doesn’t simply store the original file. It converts the image into a bitmap and wraps it in an OLE container. This conversion happens regardless of the original file format — whether it was a compressed JPEG or a small PNG, it gets turned into an uncompressed bitmap internally.
The result? A file that was originally 100KB can balloon to 1MB or more inside the database. Multiply that across hundreds of records and your database grows extremely fast.
Additional problems with OLE
- Requires OLE server software — To view OLE objects, every computer running the database needs the right software registered as an OLE server. If someone opens your database on a machine without the right programs installed, the images may not display at all.
- You can’t see the original file — OLE shows you the bitmap version, not the original. So editing the image means going through layers of conversion.
- Performance degrades quickly — Large OLE-heavy databases get slow and sluggish. Users experience noticeable lag when opening forms.
- Database size limit — MS Access has a 2GB file size limit. OLE objects can push you toward this limit surprisingly fast.
Verdict on OLE
Avoid it. It was a reasonable solution in the 1990s, but today it causes more problems than it solves. Even Microsoft has quietly moved away from it.
Method 2: Attachment Field
Microsoft introduced the Attachment data type in Access 2007 as a replacement for OLE. It stores files in their original format — a JPEG stays a JPEG, a PDF stays a PDF — without the bitmap conversion problem. You can also attach multiple files to a single record.
On the surface this sounds much better. And in some ways it is. But it has its own set of limitations.
How it works
You create a field with the Attachment data type. In Datasheet View, this field shows as a paperclip icon. Click it to add files. Access stores the attached files inside the database in their native format.
Why it’s still not ideal for most use cases
- Database still grows — Even though files are stored more efficiently than OLE, they’re still embedded inside the
.accdbfile. A database full of image attachments will still grow large and eventually become unwieldy. - Harder to work with in forms and reports — Displaying attachment images in forms requires binding an Image control to the attachment field, which works but adds complexity. Reports in particular can behave inconsistently with attachment images.
- Not easy to extract or manage files — If you ever need to get your files out of the database (for backup, migration, or sharing), it requires extra steps. The files aren’t simply sitting in a folder you can open.
- Performance concerns — For databases shared across a network, large attachment fields slow things down noticeably.
- Still inside the database — Any corruption of the
.accdbfile puts all your attached images at risk.
Verdict on Attachments
Better than OLE, but still not the best choice for any database where images are a primary feature. Fine for occasional document attachments on a small, single-user database — but not for anything that will grow or be shared.
Method 3: File Path — The Recommended Approach
Here’s the method that experienced Access developers actually use. Instead of storing the image inside the database, you store the image outside the database in a folder — and save only the file path (the location of the image) in a regular text field.
When you want to display the image on a form or report, you use an Image control and point its source to the path stored in that text field. Access reads the path, finds the file, and displays it.
Why this works so well
The database stays lean. Your .accdb file only contains text — paths and filenames. The actual image files live in a dedicated folder. This keeps the database small, fast, and well within Access’s 2GB limit no matter how many images you add.
Images are easy to manage. Because your photos are just regular files in a folder, you can open them, edit them, back them up, rename them, and move them using normal Windows file management. Nothing is locked inside a binary database format.
Performance stays fast. Loading a path from a text field and rendering an image from a file is much faster than unpacking an OLE object or extracting an attachment. Forms open quickly and scroll smoothly even with many image-heavy records.
Network-friendly. If your database is shared across a network, storing images in a shared folder (accessible to all users) means everyone gets fast image loading without bogging down the database file itself.
No special software needed. Access displays image files directly using its built-in Image control. No OLE servers, no extra programs.
How to set it up
The setup is straightforward:
- Create a text field in your table (e.g.,
PhotoPath) to store the image file path - On your form or report, add an Image control
- Set the Image control’s Control Source to the
PhotoPathfield - Store paths like
C:\EmployeePhotos\john_smith.jpgin thePhotoPathfield - Access reads the path and displays the image automatically
For databases meant to be used on multiple computers, use relative paths or a shared network folder path so the images are accessible to everyone.
One thing to keep in mind
Because the images live outside the database, you need to manage them separately. If someone deletes or moves an image file, the form will show a broken image placeholder for that record. A little file management discipline goes a long way — keep images in a dedicated, backed-up folder and you’ll have no issues.
Side-by-Side Comparison
| Method | Stores Image In | Database Size Impact | Performance | Complexity | Recommended? |
|---|---|---|---|---|---|
| OLE Object | Inside database (as bitmap) | Very high | Poor | Low setup, many problems | No |
| Attachment Field | Inside database (native format) | High | Moderate | Moderate | Rarely |
| File Path | External folder | Minimal | Excellent | Low | Yes |
A Practical Example: Employee Photo System
Imagine you’re building an employee database with a profile photo for each person. Here’s how each method plays out in practice:
With OLE, you’d insert each photo and Access converts it to a bitmap. After 200 employees, your database is massive, sluggish, and full of bloated image data no one can easily access.
With Attachments, photos are stored more cleanly, but your database is still growing with every record. Opening the form on a shared network drive is noticeably slow.
With File Path, you create a folder called EmployeePhotos next to your database file. Each employee’s photo is saved there with a consistent naming convention (like their employee ID). Your table stores the path to each photo. The database file itself stays small, forms open instantly, and backing up photos is as easy as copying a folder.
The difference in day-to-day experience is significant — and it only gets more noticeable as the database grows.
Final Thoughts
Storing images in MS Access is something many people do without thinking too much about the method. They pick OLE because it’s the first thing they see, or Attachments because it sounds modern, and then months later wonder why their database is 1.5GB and crawling.
The file path approach takes an extra minute to set up the first time, but it’s the right foundation for any database that will be used regularly, shared with others, or expected to handle a meaningful number of images.
Keep images in a folder. Store paths in your database. Display them with an Image control. It’s simple, fast, and exactly how the pros do it.
Watch the full tutorial on YouTube: What is Best to Store Images and Objects in MS Access by Skill Header, and download the practice files at skillheader.com.
