What we will never do
These commitments also appear on the about page, and they are permanent:
- There will never be display ads on this site.
- Your data will never be sold. We share it only with the services that run the parts of the site you use, listed under who receives your data.
- There is no third-party tracking. No advertising pixels, no external trackers, no cross-site profiling.
- Analytics never use cookies and never store your IP address.
- You never need an account or a subscription to use the site.
Browsing the site
You can use every dashboard, map, and article without telling us anything about yourself. We measure site usage with a self-hosted, cookie-free analytics tool (Umami) running on our own server. It records aggregate information such as pages viewed, referring sites, browser and device type, screen size, and country. From a page's address it keeps the path and, when a link from our API, our MCP server or ChatGPT labels where it came from, that label. It never keeps anything else after the "?", or anything after a "#". It does not use cookies, does not store your IP address, and does not build a profile of you. No analytics data is shared with any third party, except that our email provider carries a daily email to the site operator. It gives site-wide totals, such as pages viewed, postcode checks and orders, and lists each sale with its product, price, time and postcode district. It holds no email address, full postcode or report reference. To keep automated traffic apart from people, that email sorts browsers by what analytics already records: country, screen size, pages viewed, referring site and events. Nothing extra is collected for it. The analytics records themselves stay on our server.
When you use a postcode check, analytics records which page the check was on and whether it found published data, never the postcode itself. Pages whose address is a private link, such as a report status page or a report pack page, are recorded under a generic address, so the private part of the link never reaches analytics.
Our server also records a few steps itself, because they can finish after you have closed the page: a free report ordered, a free report first opened from its email, a report or pack checkout (with the product and the amount paid), a voucher redeemed, and an area alert confirmed. Each record says only which step happened. It carries no email, postcode, area, reference code, or IP address, and it is not linked to your visit to the site.
Our server also counts, each day, the requests that name a known search or AI crawler, such as Googlebot or GPTBot, in their User-Agent. It keeps only the crawler's name and the day's total, never the page, the address, or the rest of the User-Agent, and those totals go into the same daily email.
If you check a postcode
When you check a postcode for published records, we find its location in our copy of the ONS Postcode Directory, and send it to postcodes.io only when our copy does not have it. We keep the postcode and its result in a temporary cache for up to six hours, so a repeat check is quick. The check opens a result page whose address carries the postcode after the "?", so you can bookmark it or send it to someone, and it stays in your browser's history like any page you visit. Our web server's request log drops that part of every address, and analytics never records it. Anyone you send the address to sees the same published figures. The page's street map is drawn on our server from cached OpenStreetMap tiles, so your browser does not contact OpenStreetMap. The tile requests our server makes name the site only, never a postcode, a visitor or an email address. The map tiles for a checked area stay in our server's tile cache for at least seven days, and notes of when each tile was last queued or refreshed stay for up to a day. A background job on our web server that fetches missing or expired tiles is given only their tile numbers, and is dropped if it cannot start within a minute. All of these are filed by map tile, each about 400 metres across, not by postcode, and hold no postcode and nothing about you. We store nothing else from a check.
District and council area pages draw their street maps the same way: on our server, from the same cache of OpenStreetMap tiles, so your browser does not contact OpenStreetMap for them either. Their tiles are from about 400 metres to about 25 kilometres across, depending on the size of the area, and are fetched by tile number alone. Each map is filed by its area's page, such as E8 or the Chelmsford council area, never by postcode, and records nothing about who viewed it.
If you order a neighbourhood report
For each report request we store:
- the email address, which the free 12-month report requires and paid reports make optional. We use it to send a free report's link and reference, to send a ready notice, to apply the daily free-report limit, and so you can match a request later. For a paid report, it also goes to Stripe for checkout.
- the postcode searched, plus an anonymised version for display
- the latitude and longitude derived from geocoding the postcode
- the report status, generated file path, and timestamps, including when the emailed link of a free report was first opened
- a report reference code (for example
SSUK-…) used to reopen the status and download pages
That information is used only to generate the requested PDF, take payment for a paid report, let you reopen the request later, deliver access to the file, and count how many reports are ordered and opened. It is never included in analytics: report references, emails, and postcodes stay out of usage measurement entirely.
When you start a paid checkout, we keep a checkout record before you pay: the product, the postcode and its coordinates, your email if you gave one, any discount code, and the price. If you use a discount code, we also record your email, the product and the price against that code, so a code limited to one use per email works.
How report access is protected
Single-report status and download pages are opened with your report reference on Find a report. Anyone who has that reference can reopen and download the report, so keep it private. The free 12-month report also arrives as a signed link that opens its status page for 30 days. Treat that email as private too. Paid reports have no such link - the reference is the access key. Status pages show an anonymised postcode to reduce unnecessary exposure.
Prepaid report packs work differently: the pack confirmation email includes a private pack-page link (with an access token in the URL) that lists your voucher codes. Each voucher is then redeemed for a normal report that gets its own report reference.
Monthly area alerts
If you sign up for free monthly area alerts, we store your email address, the postcode district you chose, when you signed up, confirmed, and unsubscribed, which version of the consent wording you agreed to, and which months we have emailed you. We first send one email with a confirmation link. We send monthly alerts only after you open that link and press Confirm monthly alerts, and they cover only that district. To stop them, open the unsubscribe link in any alert and press Unsubscribe; email apps that support it also offer one-click unsubscribe. Under the Privacy and Electronic Communications Regulations, your consent is the basis for sending the alerts; we keep the record of it so we can show when and how you agreed. Your email and district are never sent to analytics, and apart from our email provider, which delivers the alerts, no one else receives them. To have the record deleted, contact support@crimemapsuk.com.
Help and feedback form
If you use the help and feedback form, the site emails us the category, subject and message, and your name and email address if you give them. The site's database does not keep a copy. The email stays in our support mailbox so we can read and reply. Those details are not used for marketing and are not sent to analytics.
Our API and MCP server
Anyone, including software and AI assistants acting for their users, can call our API or its MCP server for district figures without a key. When a call includes a postcode, the API reads the postcode district from it (E8 from E8 1AA) and answers with that district's published figures. It does not send that postcode to postcodes.io or store it. Our web server's request log records each page address without the part after "?", which is where a postcode travels, and shortens the address of the page you came from the same way. If a request fails inside our server, our web server's error log can record that request's full address, including a postcode, and those error logs are deleted after 15 days. The postcode summary finds the postcode's location and keeps the postcode and its result in a temporary cache for up to six hours, as a postcode check on the site does, so it sends the postcode to postcodes.io only when our copy of the ONS Postcode Directory does not have it.
A call to the MCP server is a request to the address /mcp, and the postcode or district asked about travels inside the request, not in its address. Our web server's request log records the caller's IP address, the time, the address /mcp, the response code and size, and the name the calling software gives itself. It never records what was asked or answered. Request logs are deleted after about 15 days. The MCP service keeps no request log of its own and does not log the postcodes or other inputs of tool calls. The MCP server's postcode_summary tool finds the postcode's location as the postcode summary does, with or without a key.
To enforce the free limits, which the API page lists, the server counts each caller's recent calls under a one-way hash of the IP address (for an IPv6 address, of its /64 network), in the temporary store described below. Calls from the published networks of Anthropic, Google and OpenAI are counted under the platform's name instead, so all of one platform's users share one allowance. Our web server also caps how fast one IP address can send requests to the MCP server, counting in memory only. Links in answers carry a label saying they came from the API or the MCP server, so analytics can count those visits. The label names no caller, postcode, or key. The server also counts answered calls per endpoint and tool each day, and answered and rate-limited calls by the allowance they draw on (one of the AI platforms above, other callers without a key, or callers with a key), with no caller, postcode, or key. Those totals go into the daily email described under "Browsing the site".
Business API plans
If you buy an API plan, you pay on Stripe's payment page, not on this site. Stripe collects your card and billing details there, under its own privacy policy, and passes us the name and email address you enter and the plan you chose, never your full card number. We store your organisation's name and contact email with your API key, and count your requests each month against your quota. We use your email address only to send your key and to contact you about your plan. It is never used for marketing or sent to analytics.
Who receives your data
We use these services to run the site:
- Hetzner hosts our server, which runs the site, its database and our analytics.
- Stripe takes payment for paid reports and packs. We send it the product, the price and your email address if you gave one. For a report, the link that brings you back to the order form if you cancel also carries the postcode. You enter your card details on Stripe's page, and we never see them. Stripe also takes the monthly payment for a business API plan. You enter your details on its payment page, and it passes us your name, email address and the plan you chose.
- postcodes.io turns a postcode into a location. Our server sends it the postcode when you check a postcode, order a report or redeem a voucher, and only when the postcode is not in our copy of the ONS Postcode Directory. The map's postcode search sends it straight from your browser.
- Proton Mail sends and holds our email: report links, ready notices, pack confirmations, alert emails, help messages, API keys and the daily stats email to the site operator. It receives each recipient's address and the message.
- The map provider named in the map's credits serves the interactive map's background tiles. Your browser fetches those tiles directly, so the provider sees your IP address, as any website does. The map's code comes from our own server.
- Umami, our usage analytics, runs on our own server, as described under "Browsing the site" above.
To stop sign-ups, the free API, the map's district figures and area CSV downloads being abused, the site counts recent requests from each IP address (for the free API, the map and CSV downloads, each /64 network of an IPv6 address) in a temporary store that clears itself within two days.
Questions
If anything on this page is unclear, or you want data connected to a report request removed, use the help and feedback form. For how the crime data itself is processed, see the methodology page.