MIB Viewer

Uploading MIBs

Last updated September 10, 2026

MIB Viewer lets you upload a MIB file and browse it immediately, with no account and nothing installed. This guide covers uploading, what happens when you upload a newer revision of a MIB already in the shared database, and what does and doesn't survive after you leave the page.

Uploading a file

Drop a file onto the upload zone in the sidebar, or click it to browse. .mib, .txt, and .my are all accepted.

The MIB Viewer sidebar showing the upload drop zone, labeled 'Drop MIB files here, or click to browse - .mib, .txt, .my supported'
The upload zone is at the top of the sidebar on every page.

The file is sent to the server to be parsed, but it is not added to the shared database. It's saved and parsed so you can browse it, but nothing about the upload is visible to other users. Adding a MIB to the shared database is a separate, manual process.

What you get after uploading

A feedback line above the search box confirms the upload, and the MIB appears in a new "local-only" section in the sidebar, tagged LOCAL.

Upload feedback reading 'new_mib.mib saved locally', with a new '1 local-only MIB' section in the sidebar showing JUNIPER-DOM-MIB tagged LOCAL
The feedback line confirms the upload; the MIB appears under its own "local-only" heading, separate from the shared database list below it.

Opening it shows the same MIB view as a shared MIB - object table, OIDs, access levels, descriptions, type filters, Generate SNMP Command. The one difference: no Download button, since download only applies to files already in the shared database.

A fully parsed local MIB view for JUNIPER-DOM-MIB, showing the LOCAL badge, an Imported Objects section noting SNMPv2-SMI as missing, and a populated object table with real OIDs and descriptions
A local preview works the same as any other MIB view. The Imported Objects section here flags SNMPv2-SMI as missing, since this preview only has what was in the uploaded file.

A local preview resolves against the shared database plus anything else you've uploaded this session. If a file's IMPORTS clause references a MIB that isn't in either, that dependency shows as missing rather than being guessed at.

Uploading the same MIB twice

Uploading a file whose module name matches one already in the shared database is rejected. Nothing changes, and the feedback line says so.

Upload feedback reading 'older_syslog.mib already have this', shown in amber, with the sidebar unchanged
A module name already in the shared database is rejected outright.

The match is by the MIB's declared module name - the name after DEFINITIONS ::= BEGIN - not filename or file content. A different filename, different whitespace, or different line endings is still recognized as the same MIB.

The exception: a newer revision

One case is not rejected: a file whose LAST-UPDATED value is later than the one already stored. LAST-UPDATED is the timestamp every well-formed MIB declares in its MODULE-IDENTITY clause, and it's the only thing compared - not the upload date, not anything else about the file. A later value lets the upload through as a local preview instead of being rejected.

Upload feedback reading 'newer_syslog.mib newer version - previewing locally', with the sidebar showing two local-only MIBs (JUNIPER-DOM-MIB LOCAL, and CISCO-SYSLOG-MIB LOCAL NEW) and the shared list showing CISCO-SYSLOG-MIB tagged OLD
A newer LAST-UPDATED is let through as a preview. Both sides are tagged: NEW on the local upload, OLD on the shared MIB it's newer than.
  • The comparison is strict - equal or older values are still rejected.
  • If either file's LAST-UPDATED can't be determined, the upload is rejected rather than guessed at.
  • This doesn't touch the shared database. The NEW/OLD tags apply only to your own session; the shared copy is unchanged.

The NEW/OLD tags also appear in "Search MIB name" results.

Searching 'CISCO-SYSLOG' in the sidebar search box, showing one local-only match tagged LOCAL and NEW, and one shared match tagged OLD
Searching by name shows both the local preview and the shared original, tagged the same way.

What persists, and what doesn't

A local preview exists only in that browser tab's memory, for that session. Refresh the page, close the tab, or come back later, and it's gone - not archived, not recoverable.

Opening an uploaded MIB updates the URL to something like ?mib=JUNIPER-DOM-MIB, the same as a shared MIB. Refreshing at that URL:

After refreshing the page while the URL still shows the local MIB's module name, the app has landed on an unrelated 'enterprises' tree node instead, and the sidebar's local-only section has disappeared entirely
The URL still reads ?mib=JUNIPER-DOM-MIB, but the preview is gone. The app falls back to a default tree page, with no message explaining the change.

The URL only ever held a module name. Resolving a name requires a lookup, and a local-only preview exists only in that tab's memory - there's nowhere else for the lookup to find it. To return to something you uploaded, upload it again.

The raw file itself is saved to the server. What's lost on refresh is the parsed preview built from it. That saved file isn't something you can retrieve through the interface - it's available for an administrator to review and add to the shared database separately, outside this upload flow.