the repayment, and what changes it.
mortgage calculators on lender sites are marketing. they give you a monthly figure, they do not show the total interest, and they certainly do not show you what happens if you overpay by fifty a month.
the arithmetic is not complicated. what is missing is a version where every input is visible and you can move one and watch the answer.
so build that. your numbers, your assumptions, the amortisation shown, and nothing selling you a product.
the sums, with the total shown.
01 / what it isthe useful outputs of mortgage arithmetic are the monthly payment, the total interest over the term, and the effect of paying more. lender calculators show the first, because it is the smallest number. showing all three on one screen changes how the decision looks.
it is arithmetic on figures you supply. it does not know what rate you will be offered, what happens at the end of a fixed period, or any of the fees, and the page says so rather than implying a precision it does not have.
- the monthly repayment, and the total interest beside it
- the full amortisation, year by year
- what an overpayment does to the term and the total
- a comparison of two scenarios side by side
- every assumption as a visible input
- a plain statement of what it does not model
- what you supply
- amount, rate, term, and any overpayment or fee you want modelled
- what it computes
- repayment, total interest, amortisation, and overpayment scenarios
- what it excludes
- rate changes, fees you did not enter, tax, insurance — stated on the page
- what it is not
- financial advice or an indication of what any lender will offer
see one in action.
02 / exampletotal interest is shown as prominently as the monthly figure, which is the number lender calculators leave out.
copy this, then make it yours.
03 / starting prompta starting point, not a template — the point of an agent is that the result is yours. change the sections to match what you want, and remove anything you don’t need.
Build me a mortgage calculator as a single web page. Show the working.
Ask me first:
- My currency.
- Whether I want repayment, interest-only, or both.
- Whether to model overpayments — regular, one-off, or both.
- Whether I want to compare two scenarios side by side.
- Whether the page should remember my inputs in this browser or forget them.
Do not prefill a rate as though it were a market figure. If you supply a starting value, label it clearly as an arbitrary placeholder.
WHAT IT DOES
- Inputs: amount borrowed, annual interest rate, term. All visible, all editable, nothing hidden in the code.
- Outputs, all at once: monthly repayment, total repaid, and total interest. Give the total interest the same visual weight as the monthly figure — it is the number lender calculators bury.
- A full amortisation schedule, at least by year and expandable to months: payment, interest, principal, remaining balance.
- Overpayments: a regular monthly extra, a one-off lump sum, or both, showing the effect on the term and on total interest. This is the most useful thing on the page.
- If I asked for comparison: two scenarios side by side with the differences stated as numbers.
- Recalculate as I type, so I can see which input the answer is sensitive to.
WHAT IT MUST NOT DO
- Do not fetch rates, indices or any market data. No network requests.
- Do not recommend a product, a lender, a term, or a strategy.
- Do not imply the figures are an offer, a quotation, or what anyone will actually lend.
DESIGN
- Inputs and results on one screen on a laptop so cause and effect are visible together.
- Monospace numbers, aligned columns, currency formatted consistently.
- The amortisation table should be readable and scrollable rather than crammed.
BE HONEST ON THE PAGE
- State what the calculation excludes: rate changes after any fixed period, arrangement and valuation fees unless I entered them, insurance, tax, and early repayment charges.
- State that it is arithmetic on figures I supplied and is not financial advice.
- If inputs are remembered, say they are stored in this browser only.
DELIVERY
- Produce one self-contained HTML file. Inline the CSS and JavaScript.
- No build step, no server, no framework, no package install, no external
requests at runtime.
- Mobile-first and responsive; it has to be usable one-handed on a phone and
still look right on a laptop.
- Accessible: semantic HTML, real contrast, visible keyboard focus, labelled
controls, touch targets big enough to hit, and respect reduced-motion.
- Use placeholders where information is missing. Do not invent facts, numbers,
names, dates, prices, or results I have not given you.
- Before you call it finished, use it yourself: enter real-looking data, reload
the page, and confirm nothing is lost or mangled.
PUBLISHING
Publish the finished page to HTMLShare and give me the link.
Use exactly one of the two paths below, preferring the first. Make the call
directly. Do not route it through a code sandbox, container, or computer-use
session — that is where the request gets blocked, and it is never necessary.
1. An HTMLShare integration or connector, if you have one configured.
The page is permanent and owned by my account. Report the url and the
siteId. There is no claimUrl or manageToken on this path — do not go
looking for one, and do not switch paths in order to produce one.
2. Otherwise, publish anonymously over REST. No account, key, or signup is
needed:
POST https://api.htmlshare.net/v1/publish
content-type: application/json
{"html": "<!doctype html> ... "}
The reference is https://htmlshare.net/docs and, for the full schema,
https://api.htmlshare.net/openapi.json
Report these from the response, in your reply and never inside the page:
url the public page
claimUrl a private link that is mine alone. opening it is how I keep
the page past its 24-hour expiry, or set an email reminder
before it goes. it carries the manage token, so it must
never appear in the published HTML or anywhere a visitor
could see it.
manageToken the only thing that can edit or delete this page later. it is
returned once and never again, so tell me what it is.
Tell me which of the two you used. If the path you reach for first is
unavailable in your environment, say so and tell me what you are switching to
before you publish — a permanent page on my account and a 24-hour anonymous
page are different things, and which one I get is my decision, not a detail.
If I ask for a change afterwards, update the existing page instead of
publishing again, so the URL I have already shared keeps working — through the
same integration on path 1, or with the manage token as an X-Manage-Token
header on path 2.
RECIPE MARKER
Include this tag in the <head>, exactly as written:
<meta name="htmlshare-recipe" content="mortgage-calculator">
It tells htmlshare which recipe the page came from, so the library can count
that this one was actually made. It carries nothing else.give it a url.
04 / publishing ithow you publish depends on how you’re working.
- with an integration
- if your assistant already has htmlshare connected — mcp or another supported integration — just ask it to publish the finished page and hand back the url. the page belongs to your account and is permanent. when you want a change, ask for an update to that same page rather than a new one.
- with no integration
- the prompt tells the assistant to post the html to the rest api instead, which needs no account and no key. it comes back with a live url you can open immediately, a private claim link, and a manage token. the claim link is how the page stops being temporary — keep it.
- by hand
- nothing stops you doing it yourself: have the assistant give you the html file and drop it on the htmlshare home page. same url, same page, one more step.
- what matters here
- this is a page you reopen every time a rate or an offer changes. claim it, and keep real figures typed in rather than baked into the html.
you will run this again next week.
05 / keeping it aroundfine for one session — it stores nothing, so an anonymous publish gives you the calculator for a day before it stops serving, with a 7-day recovery window.
claim it if house-hunting is going to take longer than a day, which it is.
- keep it around
- house-hunting takes months and you will rerun this at every offer.
- custom url
- a page you can get back to without rebuilding it each time.
- stable updates
- you will want another scenario modelled. add it at the same address.
questions.
06 / questionsdoes it know current rates?
no. it makes no network requests, so every figure is one you typed. that also means it cannot show you a rate that has quietly gone stale, which lender pages frequently do.
is it accurate?
the arithmetic is, on the inputs you give it. what it does not model — fees, rate changes after a fixed period, early repayment charges — it is told to list on the page, so you can see the gap between it and a real offer.
is this financial advice?
no. it compounds numbers you supply and says so. what any of it means for your situation is a conversation with someone qualified.
are my figures saved?
not by default — it calculates and forgets. if you asked it to remember them they are in your browser only and never sent anywhere.