1995: “Where are you?” was a form field, not an API call

In the mid-1990s, “dynamic web” typically meant an HTML form that submitted data to a server-side program—often via CGI. If a site wanted to show localized content, it usually had to ask directly:

• ZIP code for weather forecasts or store locators
• City and state for local directories
• Country selection for international shipping or localized phone numbers

This may sound primitive compared to today’s “Allow location?” prompt, but it established a key web API concept: the user is a data source, and the browser is the conduit. Forms provided a consistent interface across browsers, and CGI offered a universal server-side integration point.

Importantly, early “contextual web experiences” weren’t only about geography. They were also about session context: what a user clicked, what they searched for, and what they typed into a form. In 1995, those were the primary signals the web could reliably capture.

1996: Cookies and the first wave of personalization

By the mid-1990s, cookies were becoming a practical building block for personalization. While the early web was largely stateless, cookies gave developers a way to persist lightweight preferences across requests.

For “location-like” experiences, cookies enabled a pattern that shows up repeatedly in API history:

1. A site asks for location information (often a ZIP code) once.
2. The server stores that preference (commonly in a cookie or server-side session).
3. Future pages automatically tailor content without asking again.

This is a major conceptual precursor to the Geolocation API: a user grants information once, and the site uses it to make subsequent experiences more relevant.

However, the mid-90s approach had a critical difference from modern browser APIs: it was mostly site-controlled. There was no standard permission UI, no browser-managed revocation flow, and no consistent developer contract for what “location” meant.

1995–1997: Browser scripting starts to shape “context” on the client

The introduction and rapid spread of JavaScript (originally created in 1995) changed the nature of dynamic integration. Client-side scripting enabled pages to react immediately to user input and to infer bits of context without a round trip to the server.

Even without true geolocation, developers could approximate locale and environment signals such as:

• Time and time zone hints: the client’s clock (useful for scheduling and “open now” style experiences, though not reliable for location)
• Language preferences: through HTTP headers (processed server-side) and browser settings, enabling localized content
• Screen and browser capabilities: shaping content layout and media choices—an early form of context adaptation

This matters in the Geolocation API story because web APIs don’t emerge in isolation. They appear when the platform has enough supporting pieces: scripting, event handling, state management, and patterns for requesting sensitive data.

In the 1995–1998 window, the web was assembling those pieces. Developers were learning to treat the browser as more than a document viewer—more like a runtime where inputs could be gathered and outputs could be personalized.

CGI + early “IP-based location” guesses: contextual, but fragile

Another mid-90s pattern that foreshadowed geolocation was the attempt to infer a visitor’s region from network information. Servers always had access to a client IP address (or something close to it, depending on proxies). Developers could sometimes map that to:

• ISP or organization domain
• Country-level hints
• Occasionally a city or region, with varying accuracy

During 1995–1998, this kind of inference was inconsistent and often wrong—dial-up pools, corporate gateways, and shared connections made “where” a fuzzy concept. But it demonstrates an early appetite for a standard: developers wanted a reliable, browser-mediated location signal rather than a best-effort server-side guess.

In retrospect, you can see how the web was heading toward a more formal contract: a standard interface (API), a defined data type (coordinates), and a user permission model.

1997–1998: Toward richer integration (and the need for standard APIs)

By the late 1990s, web teams were stitching together early “application-like” behaviors from multiple layers:

• HTML forms for structured input
• CGI and server scripts for dynamic responses
• Cookies for continuity
• DHTML-era techniques for dynamic updates and interface effects (varying by browser)

This patchwork created momentum for standards. The web’s history is full of moments where developers achieved something useful in an ad hoc way first—and only later demanded a stable API to do it safely and consistently.

Geolocation follows that arc. The “contextual web experience” was already valuable in 1995–1998; what was missing was a secure and interoperable way to access high-quality location data.

Why this era matters to Geolocation API history

It’s tempting to treat the Geolocation API as a purely modern invention, tied to smartphones and GPS. But the mid-90s web contributed several enduring patterns that show up in today’s geolocation and permissions-driven APIs:

1. Progressive data collection: ask for minimal information first (ZIP code), then refine as needed.
2. State and preference storage: cookies and sessions prefigured “remember my choice” experiences.
3. Client/server division of labor: browser scripting for immediacy, server scripts for heavy lifting and integration.
4. Context as a product feature: the web learned that relevance (local news, nearby stores) boosts engagement.
5. The privacy pressure: even when location was user-entered, it raised questions about tracking and persistence.

Those patterns set the stage for later web APIs that explicitly acknowledge sensitive data. When you look at modern documentation for the Geolocation API—like the authoritative reference on MDN Geolocation API documentation—you’ll see concepts that mid-90s developers didn’t have: secure contexts, permission prompts, and standardized error handling. The need for those safeguards makes more sense once you remember how quickly “context” became a competitive advantage.

From “ZIP code” to “Allow location”: the through-line

In Chapter 95’s timeframe (1995–1998), the web was inventing its own integration playbook. A user would provide inputs, a server would generate a tailored page, and cookies would preserve choices. That workflow is the ancestor of modern geolocation experiences—even though the data source has shifted from manual entry to sensors and network positioning.

If you’re building modern automation or personalization systems, it’s helpful to remember that the core challenge hasn’t changed: collect context responsibly and use it to improve the experience. The tooling has evolved, and the standards are stronger, but the product motivation is the same.

For more writing at the intersection of web automation, developer workflows, and pragmatic web-building, you can also explore AutomatedHacks.com.

FAQ: Geolocation API roots and the 1995–1998 web

Did browsers have a Geolocation API in 1995–1998?

No. In that era, there wasn’t a standardized browser API for accessing a user’s physical location. Location-aware experiences were built using user-entered data (like ZIP codes) and server-side inference.

How did sites deliver “local” experiences without geolocation?

Mostly through HTML forms and CGI: users typed a location, the server generated a localized page, and cookies sometimes saved the preference for future visits.

What’s the key historical lesson for modern web APIs?

Developers usually build valuable features first with whatever tools exist (forms, CGI, cookies). Once those features become common—and the risks become obvious—the platform evolves a standard API with consistent behavior and stronger privacy and security controls.