/g/11… IDs come from a single counter shared by every entity type. Calibrated on nearly 27,000 entities dated by Wikidata, it gives the month an entity entered the graph, within three months in 85 to 96% of cases depending on the range. The second tool applies Google's original codec, rebuilt, to go from a MID to the 64-bit integer behind it, and back.
Every entity in Google's Knowledge Graph carries an ID, the MID: /m/… for those inherited from Freebase, /g/… for those Google created itself. Looking at tens of thousands of IDs, we found that /g/11… IDs are handed out in time order by one counter shared by places, people, works, brands, products and events.
Knowing the date of a few thousand entities is then enough to read the date of all the others. What you get is the date the entity entered the Knowledge Graph: useful to know since when Google has recognized a brand, a person or a product, and to spot waves of entity creation.
An entity name, a MID or a Google URL containing kgmid=: the tool returns the estimated entry month, a range and the precision to expect.
References updated on October 22, 2026 (the most recent: October 2026). A more recent ID is dated by extending the counter.
Eight base-32 characters make a number that grows over time.
A recent MID reads /g/11 followed by eight characters, for example /g/11k4jj7mq1. These characters come from a 32-symbol alphabet, 0123456789bcdfghjklmnpqrstvwxyz_, without vowels so that no word can form. The first 1 stands for the /g/ namespace; the rest, read in base 32, gives a number between 240 and 241 for every /g/11…. That number is what grows over time.
We converted into numbers the MIDs of 95,647 entities dated by Wikidata, spread over ten families: events, albums, films, games, elections, sports competitions, organizations, products, created places and opened places. Each family was dated from the nine others only, and all follow the same curve. To the year, the estimate is right for 93% of unpredictable events, 81% of albums, 76% of films, 67% of games and 46% of organizations.
/g/11b… and /g/11z… (the letter after /g/11); on the y axis, its date in Wikidata. 7,876 dots out of 26,815. Isolated dots below the curve are late entries: an old thing that gets its MID years later.The counter does not move as one block. Several assignment series progress at the same time, each in its own ID ranges. Within a series, the date grows with the MID; from one range to the next, it can go back. This is the sawtooth pattern of the /g/11f to /g/11h ranges, and the two overlapping lines from /g/11k to /g/11p, described below.
For a MID, we take the nearest dated references on either side, keep those from the same period and read the date on a curve drawn through them. References are unpredictable events, singles and albums dated by Wikidata. The announced range uses the error measured in the same range: 79 to 87% of tested events fall inside it.
To the month in nearly every range, never below the week: an event usually gets its MID one to two weeks after it happens. The /g/11k-/g/11n area, shared by two series, remains the least reliable.
| Range | Assignment years | Median error | ±1 month | ±3 months | ±6 months | Recommended precision |
|---|---|---|---|---|---|---|
/g/11b - /g/11d | 2014-2017 | 5 days | 82% | 92% | 96% | month |
/g/11f - /g/11h | 2017-2020 | 6 days | 78% | 90% | 93% | month |
/g/11j | 2020 | 8 days | 78% | 94% | 98% | month |
/g/11k - /g/11n | 2020-2026, two series | 6 days | 77% | 85% | 89% | month if the series is recognized, quarter otherwise |
/g/11p - /g/11t | 2021-2024, slow series in /g/11p since September 2026 | 5 days | 85% | 93% | 97% | month |
/g/11v - /g/11z | 2024-2026 | 5 days | 87% | 96% | 98% | month |
4,662 events dated without themselves, with the MID given by Wikidata or the one Google shows today, weighted by the real-world situation of MIDs (33-million block with or without a reference). On the MIDs Google shows, the tool is within three months in 82% of cases in /g/11k-n and 93% in /g/11p-t.
At the edge of the counter. References stop on October 22, 2026. An ID assigned after that date, in practice from November 2026 on, falls beyond them: the tool dates it by extending the counter. Recalibrating the tool at past dates, we measured that for the main series it stays within three months for 98 to 100% of events in the following two months (here until the end of December 2026), then for 82% in the third month (January 2027). For the slow series, nothing signals that it moves into a new block: the right date appears in the answer, often in second position, until the references are updated.
A first series filled /g/11k to /g/11p in 2020-2022. A second, slower one has been occupying the ranges it left free since late 2022: these are the orange dots on the chart, two to five years above the blue ones. Starting from /g/11k, it entered /g/11p in late September 2026. An isolated ID from this area can therefore date from 2021 as well as from 2026.
| Range | Fast series | Slow series |
|---|---|---|
/g/11k… | July to October 2020 | December 2022 to August 2023 |
/g/11l… | September 2020 to February 2021 | September 2023 to December 2024 |
/g/11m… | October 2020 to March 2021 | February 2025 to February 2026 |
/g/11n… | December 2020 to August 2021 | May 2025 to August 2026 |
/g/11p… | March 2021 to February 2022 | since September 2026 |
Reference dates of each series, 10th to 90th percentile.
The two series rarely mix within the same block of 33 million IDs: 837 of the 891 blocks holding at least two dated references belong to a single series. The tool recognizes the series from the ID's block or from its neighbors. When the neighboring blocks disagree, it puts the slow series first and gives the fast-series date second: the slow series was the right one for 86% of reference events in that situation. When the fast series is inferred from the neighbors, it also gives the slow-series date, because the slow series moves into blocks left free without warning.
In Google's code, a MID is a 64-bit integer. The tool goes from one form to the other, and also reads old Freebase GUIDs.
| Namespace | /m/ graph 0 |
|---|---|
| Google integer | 23345198 0x000000000164382e |
| Value (59 bits) | 23345198 ≈ 224.5 |
| Freebase GUID | #9202a8c04000641f800000000164382e |
Freebase legacy ID. The counter has been frozen since Freebase closed: no /m/ goes beyond the last GUID (/m/013fcqbq). Two topics rarely get neighboring numbers, because this counter also numbered the links between objects.
Google's code reads a MID as a 64-bit integer in three parts: 2 version bits, always 0, 3 bits for the namespace (the code's "graph ID"), then 59 value bits. The string is written as the namespace prefix (/g/), one character carrying the version and the namespace, then the value in base 32 without leading zeros, in the alphabet the code calls "munch". This is why every /m/ starts with 0 and every /g/ with 1: that first digit is not part of the counter.
For /g/11b6377dzp: 259 for the /g/ namespace, plus 1b6377dzp read in base 32 (1,449,659,708,373), giving 576462201963131861. This is the integer Valentin Pletzer spotted in 2019 in a Google search URL (ibp=tpf;cl_tp:srp,mid:576462201963131861). This MID points to "Public prosecutor's office".
| Graph | Prefix | 1st character | What it holds |
|---|---|---|---|
| 0 | /m/ | 0 | Entities inherited from Freebase. Frozen counter: 330,825 observed values, all below the last Freebase GUID. |
| 1 | /g/ | 1 | Entities created by Google. Counter assigned in blocks, often homogeneous: places, songs, adjectives. |
| 2 | /t/ | 2 | Several observed uses: products on merchant sites, image subjects (a separate family), groups of entities a single word can refer to ("German": Germany, German language, Germans), old k'nex interest themes (/t/236, Tennis). Likely common ground: entities built alongside the graph. 59 uniform bits: not a counter. |
| 3 to 5 | /x/ /n/ /p/ | 3 to 5 | Planned in the code, never observed. |
| 6 and 7 | /r/ /s/ | - | Reserved, never observed. |
The source file metaweb/util/mid/mid.cc is not public. Its path recalls where the codec comes from: Metaweb, the company that built Freebase before Google bought it in 2010. We got hold of the binary of the original codec and rebuilt it in C++. Logic, constants, messages and line numbers come from the binary. Function and variable names are ours: the binary no longer holds any.
// metaweb/util/mid/mid.cc // reconstruction: the logic is the binary's, the names are ours static const char kMunch[] = "0123456789bcdfghjklmnpqrstvwxyz_"; static const string_view kPrefix[8] = {"/m/", "/g/", "/t/", "/x/", "/n/", "/p/", "/r/", "/s/"}; static const uint64_t kMaxValue = 0x7ffffffffffffff; // 2^59 - 1 uint64_t MakeMid(int graph, uint64_t value) { if (value >> 59) { VLOG(1) << "Mid exceeds max size 0x" << hex << kMaxValue // line 226 of the source file << " for namespace " << kPrefix[graph] << ": 0x" << value; return -1; } if (graph == -1) return -1; return value | (uint64_t(graph) << 59); } bool ParseMunch(string_view s, uint64_t* out) { if (s.size() > 13) return false; if (s.size() == 13 && kMunchValue[s[0]] > 15) return false; // would exceed 64 bits uint64_t v = 0; for (char c : s) { int d = kMunchValue[c]; // -1 outside the alphabet if (d < 0) return false; v = (v << 5) + d; } *out = v; return true; } uint64_t GuidToMid(string_view guid) { if (guid.size() != 32) return -1; uint64_t hi = HexToU64(guid.substr(0, 16)), lo = HexToU64(guid.substr(16, 16)); uint64_t graph = hi - 0x9202a8c04000641f; // unsigned comparison if (lo < 0x8000000000000000 || lo > 0x80000003ffffffff || graph >= 8) return -1; return MakeMid(graph, lo & 0x3ffffffff); // 34 value bits } uint64_t ParseMid(string_view s) { if (s.size() >= 4 && s[0] == '/' && s[2] == '/') { int graph; switch (s[1]) { case 'm': graph = 0; break; case 'g': graph = 1; break; case 't': graph = 2; break; case 'x': graph = 3; break; case 'n': graph = 4; break; case 'p': graph = 5; break; case 'r': graph = 6; break; // reserved, never observed default: return -1; // 's' included, no message } char c0 = s[3]; if ((c0 & 0x78) != 0x30) return -1; // '0' to '7': version 0 uint64_t value; if (c0 == '7' || !ParseMunch(s.substr(4), &value)) { VLOG(1) << "Invalid mid characters: " << s; // line 256 of the source file return -1; } uint64_t mid = MakeMid(kMunchValue[c0], value); if (mid == -1) return -1; return ((mid >> 59) & 7) == graph ? mid : -1; // letter and digit must agree } if (StartsWith(s, "/guid/")) return GuidToMid(s.substr(6)); if (StartsWith(s, "#")) return GuidToMid(s.substr(1)); return -1; } string MidToString(uint64_t mid) { if (mid == 0) return "/m/0"; uint64_t top = mid >> 59; // version + graph if (top >= 7) return ""; // /s/ or non-zero version char buf[13]; return StrCat(kPrefix[top], kMunch[top], MunchDigits(mid & kMaxValue, buf)); // base 32 without leading zeros }
VLOG(1) is a reading of the binary: before writing, the code tests a log level, but the exact macro is unknown. kMunchValue is the reverse alphabet table, MunchDigits writes the digits right to left into a 13-character buffer.
The file holds only two error messages: "Mid exceeds max size 0x… for namespace …" at line 226, when a value exceeds 59 bits, and "Invalid mid characters:" at line 256, when a character falls outside the alphabet. An unknown prefix, a /s/ or a letter that does not match the first digit return −1 without logging anything.
Everything else is data: the alphabet, the table of the eight prefixes, the reverse table, and the two ways of writing a Freebase GUID, /guid/ and #.
What was known, what is new
Valentin Pletzer worked out long ago how a MID turns into an integer. In May 2019, seven years ago, he was the one asking the question on Stack Overflow, with the pair /g/11b6377dzp and 576462201963131861 spotted in a Google URL. The rule, 259 for the /g/ namespace plus the remainder read in base 32, is in his gist, which converts a MID into a number and back.
The alphabet and the conversion of /m/ IDs from Freebase GUIDs have been documented since 2010, and Google published in 2020 a Python code from the Freebase era (pymql). Its mql/mid.py file keeps four Freebase GUIDs as examples, one of them copied twice. Decoded, they give three distinct entities, which Google still shows: /m/0r5_5s, /m/0q8g1g ("American Dream (Afterlife mix)") and /m/0mx1ng ("Young and Fine", a Weather Report song).
What we add: the full codec with its checks, rebuilt from the original binary. All 3.4 million MIDs in our corpus pass the codec, round trip included, against 2.7% for random strings. 27 of the 30 integers found in Google URLs point to the entity searched for.
What a MID does not contain. No check digit: 37,258 groups of /g/11 IDs differ only by their last character, so a typo passes the codec checks. No computable link between the /m/ and the /g/ of the same entity (13,492 pairs tested), nor with the Wikidata number, the Google Maps CID or the EAN code. The c-… IDs of Google Cloud's Enterprise Knowledge Graph contain vowels: they follow another alphabet and cannot be converted.
Nor does anything in the format say whether the entity is a product, a place or something else: all are /g/ IDs written the same way. Only the position of the value gives it away. Google creates Shopping products in batches, in reserved stretches of the /g/11k to /g/11z ranges: 94% of products have another product as their nearest neighbor, against 75% when labels are shuffled within the same period. The tool flags it when a MID falls in such a range. Old places have their own blocks; recent places, however, mix with other entities and are hard to spot. For a Google Maps listing, the MID cannot be computed from the CID or the Place ID: you have to ask Maps, which returns it with the listing when queried by its CID.
On the Wikidata side, the regular expression of property P2671 (Google Knowledge Graph ID) lists the blocks known when it was written, not Google's rule: it rejects 59 valid /g/ IDs out of 2.4 million. The exact rule fits in one line: /g/1 followed by 1 to 12 alphabet characters, without a leading zero, for a value below 259.
What about Google Maps Place IDs? Google's "Place IDs" documentation page gives five examples without saying what they point to. Decoded, they all lead to the same spot, 13 Market St in Wilmington, North Carolina, written five ways: a listing, a GPS point, the plain-text address (two variants) and a street followed by a number. Only the Place ID starting with ChIJ is a real listing, with its own MID, /g/11fj9d5c11, which the tool dates to January 2019. The other four have no listing, no reviews and no entity: an address typed in that matches no known place gets a Place ID of this kind.
The CID, a Maps listing's number (the one in maps.google.com/?cid= links), is usually a random 64-bit number: it says nothing about the place's age or location. The exception: municipalities imported in bulk from official lists, probably around 2005-2009. In France, their CIDs follow each other in steps of 16, in descending order of INSEE codes. From Bois-le-Roi (77037) to Paris (75056), the gap is exactly 781 steps: the last 35 municipalities of Seine-et-Marne, the 745 of Seine-Maritime, then Paris, according to the list in force from 2005 to 2012. In Italy, the same mechanism follows ISTAT codes, with pre-2009 provinces. The Freebase MIDs of these municipalities sometimes keep a similar trace: in Seine-et-Marne they rise with the INSEE code almost without exception, in Seine-Maritime they do not. Across 92 départements, this order is clear in 9.
How Google consolidates, ranks and displays places in Geostore: Google Map dissected.