Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.


An ArcGIS Pro basemap not loading can be a portal, service-access, display, or transport problem. Save the project, identify the actual basemap layers, and test a fresh view before changing your network: signing in successfully does not prove that its map tiles are reachable.
Key Takeaways:
- Treat the active portal, Pro license, and basemap service as separate checks.
- A familiar cached map is not evidence of a fresh service response.
- Compare one authorized basemap request without changing the account or map settings.
- Stop network testing when the evidence points to permissions, projection, or a service incident.
Save the project and make a separate diagnostic copy. Record the Pro version, active portal, basemap name, affected layer, map extent, scale, and first error. Keep your working project intact; an empty diagnostic map is useful, but rebuilding your original project is not a prerequisite for investigating a missing background.
Use the whole-workstation troubleshooting path if several applications fail together. This guide concerns the basemap service in Pro, rather than every possible Windows connection fault. A project may combine local data, private organizational services, and public background layers, each with a different access requirement.
Avoid treating a screenshot as the complete diagnosis. Record whether the failure happens at sign-in, basemap selection, or drawing a newly visited area. Remove tokens, private item addresses, usernames, and organization details before sharing a support report. Keep enough local detail to reproduce the failure without distributing credentials.
| Observation | First branch | Evidence to retain |
|---|---|---|
| Pro reports that the account is not licensed | Organization and user type | Exact sign-in error |
| Only one basemap layer fails | That service or item | Layer name and access context |
| Existing area draws but a new area stays blank | Fresh request or coverage | Extent and scale |
| All data is misplaced or invisible | Map and display configuration | Coordinate system and visibility |
| A private portal fails outside work | Approved organizational connection | Administrator's access requirements |
Open Pro's portal settings and inspect the active portal before signing out or adding another account. Confirm the organization and account expected for this project. The portal used to find content is part of the diagnosis; do not assume that a successful browser session proves the desktop application has the correct identity.
Esri distinguishes organization accounts with access to Pro from public accounts and organization members whose user type does not provide that access. An account-not-licensed message requires the organization's administrator, not a new network exit. Record the message and resolve that eligibility branch before testing tile transport. [1]
Keep licensing and content permissions separate. Being able to start Pro does not establish permission to every private basemap in an organization. Ask the item owner which portal, group, and account should access it. Do not make an item public or copy a private service URL into a public diagnostic tool to simplify testing.
If your organization requires a corporate VPN or another approved connection, preserve that requirement. A consumer VPN does not provide membership in the private network. Stop and ask the administrator when the portal or service is reachable only through the organization's network; combining tunnels without instructions can make the evidence harder to interpret.
Inspect the map's Contents pane and the basemap's constituent layers. Esri describes a basemap as one or more feature, raster, or web layers, so a missing background is not always a single failed tile endpoint. Note the layer that fails instead of labeling every symptom an ArcGIS Online outage. [2]
Check whether the layer comes from the active portal's gallery, a custom organizational item, or local data. These origins change the next action. A local raster that is unavailable needs its local source restored; an organizational layer may require group membership; a public service with repeated transport errors can justify a network comparison.
Where you have permission, use a minimal diagnostic map with the same affected basemap. Keep the source, account, and version fixed. A different public background loading successfully is evidence that Pro can draw some content, but it does not prove that the original service, credentials, or request has been repaired.
Record any item-access message separately from connection errors. Do not repeatedly try new countries to satisfy a service restriction or organization policy. If the service owner reports maintenance or a usage restriction, follow that guidance. Changing the route cannot create a service entitlement or authorize requests the owner has declined.
Check the basemap layers' visibility, scale, and expected coverage. Return to a location the selected source is supposed to cover. A valid service can still produce an unhelpful view when the current extent is outside its coverage, the relevant layer is hidden, or the map configuration is unsuitable for that data.
Esri notes that adding basemaps can affect a map's coordinate system, and that reference layers may be positioned separately from other basemap layers. Inspect the actual map and layer properties before changing them; do not prescribe a universal projection reset for every blank map. Save the original values so a diagnostic change can be reversed. [2]
If another data layer appears displaced, investigate coordinate systems and source definitions rather than purchasing a network tool. The QGIS guide to service requests and map coordinates explains a related distinction, although its WMS settings should not be copied into Pro. Here, the object being checked is the Pro basemap and its component layers.
Test display hypotheses one at a time. A diagnostic map can separate project configuration from service access, but preserve the original project's symbology and layer order. If fixing visibility or the extent restores the map without any connection change, record that result and end the network branch.
Enter this branch only for authorized public-service transport failures after checking access and display. Record the affected basemap and a new extent and scale that have not already been drawn in this session. Use that same diagnostic view for each comparison; do not change the source and route together.
Inspect any approved proxy configuration first. The Windows proxy checklist helps separate system settings from the application's connection. An organization-managed proxy may be required, and authentication or certificate failures should go to its administrator. Do not disable TLS verification or remove a managed security control to force a successful result.
For a second outbound route on the Pro Windows workstation, install AethoVPN from the official Windows download, use a desktop-capable Pro or Premium plan, and select an available location in your country or nearby where permitted. Enable global mode so the application's traffic participates in the comparison. Then retry the same basemap view, leaving the portal, account, source, and display settings unchanged.
Check the browser's exit IP as supporting evidence, and use the connection verification method to document the tunnel state. Neither check establishes that Pro received the tiles. Inspect the new map view and its errors directly; a tile already cached during an earlier attempt can otherwise make an unsuccessful route appear effective.
This route comparison cannot grant Pro licensing, organizational permissions, private-network access, or repair projection settings and service outages. Use it for the comparison, without expecting a guaranteed restoration. If you need a second path for the authorized tile request, start the three-day Pro trial; the new-user trial is available once per person.
If a VPN is already active, include an approved disconnected comparison instead of assuming that another tunnel is beneficial. Stop if the new path fails, access is refused, or policy requires the organizational network. Avoid cycling locations repeatedly or changing proxy credentials during the same observation window.
Recovery means the affected basemap draws the intended fresh area at the recorded scale, with the relevant layers present and no corresponding failed request. Confirm that the view contains new service content, not only an earlier cached image. Record the portal sign-in result separately: it answers a different question.
Use a brief evidence record: application version, authorized source, extent, scale, route state, first error, and drawing result. This is a troubleshooting comparison, not a speed benchmark or an assertion that the VPN improves Pro generally. If both paths work, you have not isolated the earlier cause; an intermittent service or expired session may also have changed.
When failures persist, send the administrator or Esri support the smallest reproducible description. Include whether a minimal diagnostic map also fails and whether the same layer works in an approved alternative network. Share private item identifiers through the organization's support channel only, with credentials and tokens removed.
Do not clear unrelated caches, reset the profile, or replace every layer as a routine final step. Such changes can destroy the comparison and create extra work. Preserve the successful settings when the issue is resolved; otherwise stop at the branch supported by the evidence and ask the appropriate owner to investigate.
Sign-in establishes an identity, not access to every map service. The basemap's constituent layers can have their own permissions or transport failures; inspect the affected layer and portal rather than repeating the login procedure.
Esri says a public account does not authorize Pro. An organization member also needs a user type that provides Pro access, so take the exact licensing message to the administrator before investigating network transport. [1]
Earlier content may be cached, or the new extent may have a different coverage or scale requirement. Test an intended fresh view and record its layer errors; an old image alone does not prove that the service is reachable.
Only change map properties when the evidence supports a display or coordinate-system issue. A projection change does not repair a failed network request, and an unexplained reset can introduce a new display problem. [2]
It does not provide the organization's private-network access or account rights. Keep the corporate connection required by your administrator, and ask for its approved diagnostic procedure instead of replacing it with a consumer tunnel.
It proves only that the browser observes a different exit. Recovery requires Pro to draw the affected fresh area with the correct basemap layers; portal status and browser connectivity are supplementary observations.
Stop when the evidence indicates denied permissions, a license issue, unsupported coverage, managed-network requirements, or a service incident. Persistent transport failures also need a redacted support report rather than unlimited retries or insecure certificate workarounds.
Sources checked 7 October 2026.
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.





