loc.is← General how-to

How to use loc.is — for agents

Use the current website workflow. Treat explorations as unstable.

Updated October 3, 2026 · Build 1

Reviewed 3 October 2026. This page describes current usage and the boundaries of our experiments; it is not a promise that every interface will remain unchanged. Verify the current documentation and behavior when you use it.

Humans and polite agents: traffic rules

This site is first and foremost for humans and polite agents. Agents and bots must not spam location links or manufacture visits to create false behavior traffic. That traffic can distort, destroy or break the site’s functionality. When detected, offending agents will be blocked or their behavior will be used to identify and filter out that traffic.

Agents acting for a user

Agents may politely and slowly navigate the site on behalf of a user. Make only the visits needed for the user’s task, avoid repeated refreshes or speculative bulk visits, and reuse already retrieved information where appropriate. Stop or back off when the site asks you to limit traffic; do not evade a block.

Report traffic as agent traffic and use an identifying agent browser header. Your browser or integration must identify itself as an agent in its User-Agent HTTP request header. Do not disguise automated visits as ordinary human browsing. If your tooling cannot identify agent traffic, do not use it to generate automated visits to this site.

Web crawlers

Web crawlers may crawl the site root and documentation pages. Limit traffic, respect the site’s published crawl rules, and do not constantly crawl location pages or enumerate location codes to generate visits. A location link is not an invitation to repeatedly revisit every possible area.

Browser look-ahead traffic

Web browser applications may generate look-ahead traffic, such as prefetching. Identify this behavior through the applicable browser or API traffic-reporting mechanism as support becomes available, so speculative requests can be distinguished from actual visits. Do not report look-ahead requests as human activity. This permission does not imply that LOCIS currently offers a public traffic-reporting API or a settled custom header.

Agents that disregard these rules are RUDE and UNETHICAL. Be transparent, keep traffic slow and limited, and preserve the site for humans and polite agents.

Current workflow

  1. Read the general how-to guide for ordinary usage. Read future considerations as exploration notes, not an implementation contract.
  2. Search for the place on the loc.is website. Select the intended result and inspect the geographic rectangle. Distinguish the venue, entrance, meeting area and wider city or park.
  3. Copy that location’s full HTTPS URL. For now, geocode on the website and copy/paste; no public geocoding API or SDK is available.
  4. Use the URL in a normal link, document, spreadsheet or invitation. Keep the place name, event details, directions and source evidence alongside it.
  5. For print, download the location’s QR code from its page, retain the white border, and scan the finished proof. A screen preview is not a physical print test.

Use a complete location URL such as https://loc.is/B9QA. This sample identifies a broad London area; it is not an exact address. Replace it with the URL of the area you checked.

<a href="https://loc.is/B9QA">London area</a>

[London area](https://loc.is/B9QA)

Do not use a custom locis:SHORTCODE scheme, invent an endpoint, or require experimental attributes for an ordinary link. The current URL is enough. A standard link does not install a hovercard, embed or metadata reader on another website.

If you need several places, use individually checked links first. The site also demonstrates comma-separated area sets; check the combined map before sharing it. A set does not encode visit order, a walking route or custom labels. Consult the current format documentation before using compound expressions.

Preview short code sharing cards

Open the Social preview studio, enter a short code such as 38MC3A or its full loc.is URL, and select Inspect page. Check the actual sharing image, title and description at desktop and mobile card widths. Inspect the compact crop for clipped text or missing location context, and review the response checks for missing metadata or image failures.

The studio works on the current server, including a local preview server. Its cards simulate sharing layouts; they do not certify Facebook output or Google indexing. Draft wording changes only the preview. Check only the codes needed for the task, and distinguish local results from live-site results in your report.

Store codes; publish full URLs

Shortcodes and longcodes may be stored or cached without the web protocol (http:// or https://) or domain name in datasets, database indexes and other internal records. A bare code is a data value; it does not need to be a clickable web link.

Internal shortcode: 683M
Internal longcode:  06080314
Public short URL:  https://loc.is/683M
Public long URL:   https://loc.is/h/06080314

Keep the encoding type with each value so shortcodes and longcodes can be distinguished. Store longcodes as text to preserve leading zeros; retain source, precision and version context where needed.

Always include the web protocol and domain when publishing to the web, encoding a 2D barcode (including a QR code), or presenting a location publicly. Use a complete HTTPS URL, such as https://loc.is/683M. Restore the appropriate route when exporting a stored longcode: https://loc.is/h/06080314. Do not publish the bare code or domain-only spelling as the location link or barcode payload.

Check location meaning and accuracy

A shortcode follows parent and child rectangles; each new tier selects a smaller sub-area inside its parent. The final rectangle is the selected area. It is not necessarily a building outline, administrative boundary or measured point.

A smaller rectangle does not improve the original GPS reading or source data. Do not call a location an “exact bench,” entrance or historical findspot unless you have evidence for that assignment. A map center is a representative point, not proof of presence.

Keep original coordinates, observation dates, record IDs, sources and uncertainty separate from the location link. When a demo is fictional or schematic, preserve that label. Publish only the location detail intended for the audience.

Uncommitted explorations

The entire future-considerations page is an exploration space. The following list highlights current examples; it is not an exhaustive or permanent feature list.

  • Hovercards, embeds and widget interfacesCompact embeds, automatic metadata discovery, article-focused information and the prototype’s data-locis, data-locis-name, data-locis-tags and data-locis-summary interfaces are not committed. A demo running on this site does not guarantee third-party integration.
  • Geocoding APIs and SDKsPlanned tooling is not available. Do not fabricate API URLs, credentials, request bodies or SDK packages.
  • Format and spatial extensionsThe experimental format is not a finalized web standard or frozen URL contract. Relative subdivisions, new normalization rules, alternate coordinate systems, floors and rooms remain unsettled. Some compound behavior exists today; that does not commit every proposed extension.
  • Metadata and IndieWeb readersStandard microformats markup and normal URLs can be authored now. Automatic LOCIS extraction, area-aware readers, geographic indexing and custom metadata conventions are explorations. LOCIS does not provide an RSVP service or Webmention receiver.
  • Time, ranking and contributed dataBulk ranking examples, additional time-zone views and optional learning/storage proposals are not committed APIs. Arithmetic examples are not measured performance claims. Longitude estimates solar phase; civil clock time needs zone rules.

When testing an exploration, identify it as experimental, check whether it actually works, and document the interface and date tested. Expect it to fail or disappear. Keep the ordinary full-URL link usable if the experiment stops working.

Report what you actually verified

Distinguish “copied and opened this URL,” “tested this local prototype,” “verified the live website,” and “tested the printed QR.” Do not upgrade one into another. Name unresolved accuracy or interface questions instead of guessing a capability.

If a task depends on an uncommitted feature, explain that boundary and use the current URL workflow where it meets the need. Check this page again before implementing integrations; previous examples may have changed.

General how-to · Explorations and web standards · AI usage policyPrivacy