⚡ AI Analyst
Add a mortgage calculator for website pages: the amortisation formula, test numbers, an AI build, and iframe embeds for WordPress, Wix, Squarespace.
Money Flock
Recommended Contents
Comments
MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.
A mortgage calculator for website pages takes four inputs, home price, down payment, interest rate and term, and returns a monthly payment plus a full amortisation schedule. You can rent one from a widget vendor for a monthly fee tied to page views, or build and host your own in an afternoon and pay nothing per view.
Think of a rented widget as a parking meter. Every visitor who stops costs you something, and the meter keeps running whether or not anyone walks through your door. A calculator you own is a driveway. You pay once to lay it, and after that the traffic is free.
This guide gives you the amortisation formula with test numbers you can check any calculator against, the exact iframe code for WordPress, Wix and Squarespace with the plan traps on each, an honest own-versus-rent cost comparison priced on 8 October 2026, and the labelling rules that keep an interactive tool from reading as advice.
Verified in the browser on 8 October 2026: lovable.dev/pricing, the Lovable Mortgage Calculator template page, calconic.com/pricing, and the WordPress.com, Wix and Squarespace support docs quoted below.
The Lovable Mortgage Calculator template page, captured 8 October 2026. The highlight chips name the features most rented widgets charge extra for.
Most visitors who open a mortgage calculator want one number: the monthly payment. The ones who stay want four more. A calculator that only returns the first number answers the question and ends the visit. A calculator that returns all five starts a conversation.
The five outputs worth shipping:
The Lovable Mortgage Calculator template ships all five. Its page lists live recalculation, an amortization table, a payment schedule chart, PMI drop-off tracking, payoff acceleration and shareable URL state, and it had 69 remixes when it was read on 8 October 2026. The stack is React, TypeScript, Tailwind CSS, Recharts, shadcn/ui, Radix UI and Lucide Icons, which matters later when you need to change a label without filing a support ticket.
The shareable URL state is the quietly useful one. When every input writes into the query string, a visitor can send a scenario to a partner, and you can send a scenario to a client after a call. Most rented widgets hold their state in memory and lose it on refresh.
Every fixed-rate mortgage calculator in the world runs the same equation. It is worth writing down, because it is the one part of the build you should never trust an AI tool to improvise and never trust a vendor to have got right without checking.
M = P x i / (1 - (1 + i)^-n)
Where M is the monthly payment, P is the loan principal, i is the monthly interest rate, which is the annual nominal rate divided by 12, and n is the total number of monthly payments, which is the term in years multiplied by 12.
Two details trip up most hand-rolled calculators. The rate must be divided by 12 before it enters the formula, not after, and the exponent is negative. Get either wrong and the payment comes out plausible but wrong by enough to matter.
$1,896.20 a month. That is the exact payment on a $300,000 loan at 6.5 percent over 30 years. If your calculator returns anything else for those inputs, it is broken.
| Loan | Rate | Term | Monthly payment | Total interest |
|---|---|---|---|---|
| $300,000 | 6.5% | 30 years | $1,896.20 | $382,633.47 |
| $300,000 | 6.5% | 15 years | $2,613.32 | $170,397.98 |
| $300,000 | 7.0% | 30 years | $1,995.91 | $418,526.69 |
| $400,000 | 6.5% | 30 years | $2,528.27 | $510,177.95 |
| $250,000 | 5.5% | 30 years | $1,419.47 | $261,010.10 |
Figures computed from the formula above and rounded to the cent. They are arithmetic, not market data, so they do not go stale, and they are the fastest way to tell a working calculator from a decorative one.
$382,633.47 in interest on a $300,000 loan at 6.5 percent over 30 years. The interest costs more than the house did.
Three derived numbers worth showing as well, all from that same $300,000 loan at 6.5 percent over 30 years:
Describe biweekly payments carefully. Paying half the monthly amount every two weeks produces 26 half payments, which is 13 full payments a year rather than 12. The saving comes from the extra payment, not from the fortnightly rhythm, and some lenders hold the half payments until a full one is due, which removes the benefit entirely. Say so in the tool.
Mortgage insurance follows a separate rule. On a $300,000 home with 10 percent down, the $270,000 loan reaches 78 percent of the original value, $234,000, at month 109, roughly nine years and one month in, with no extra payments. If your calculator shows an insurance line, it has to show when that line stops.
The fastest route is to remix the template rather than describe one from scratch. Open the template page, use it, then change the parts that are yours. If you are starting from the composer instead, the prompt that produces a usable first version looks like this:
Build a single-page mortgage calculator. Inputs: home price, down payment in currency and percent, annual interest rate, term in years, property tax, home insurance, HOA and mortgage insurance rate. Compute the monthly payment with M = P x i / (1 - (1+i)^-n), show the principal and interest split, total interest, a monthly and yearly amortisation table, and a chart of principal versus interest over the term. Add an extra-payment field that recomputes the payoff date and the interest saved. Write every input into the query string so the scenario is shareable. Label all output as an illustration, not an offer.
Four things to change before anyone sees it:
Pre-populated defaults make a tool feel alive on first load. Set the default home price to something typical for the market you serve and the default property tax to that area's usual rate. Never pre-fill the interest rate field with a number described as yours. More on that below.
Show payments to the cent and totals to the dollar, and put the assumption next to the number. A total-interest figure with no term label is a number people screenshot and argue with later.
A calculator with no next step is a dead end. One clear action under the result, a booking link or a contact form, converts far better than three. If you are collecting anything at all, read our guide to what Lovable does with financial data first, because row-level security is the difference between a lead list and an incident.
Keep lead capture optional. A calculator that demands an email before it shows the payment is a form wearing a calculator costume, and the bounce rate says so.
Most mortgage calculator traffic is mobile. Number inputs need numeric keyboards, the amortisation table needs to scroll horizontally rather than squash, and a chart that is unreadable under 400 pixels wide should collapse to a summary line.
Credits for a build like this are modest. Lovable's own example prompt costs sit at 0.50, 0.90, 1.20 and 1.70 credits, and the daily free build grant covers a lot of iteration. The arithmetic is laid out in what an MVP really costs in credits.
Once the calculator is published at its own address, embedding it anywhere is one tag. This is the part no competing guide writes down properly, because the tag is easy and the platform rules are not.
The base embed, which works on any host that allows raw HTML:
<iframe src="https://your-calculator.example.com/" title="Mortgage calculator" width="100%" height="900" loading="lazy" style="border:0;max-width:100%" sandbox="allow-scripts allow-same-origin allow-forms allow-popups" referrerpolicy="no-referrer-when-downgrade"></iframe>
Four attributes earn their place. height has to be generous, because an iframe does not grow with its content and 900 pixels is about right for a calculator with a results panel and a collapsed table. loading="lazy" keeps the embed off the critical path of the host page. sandbox with those four permissions lets the app run scripts, keep its own storage and submit its own forms while blocking it from navigating the parent page. Drop `allow-same-origin` and most single-page apps stop working, so remove it only if the embed genuinely needs nothing stored.
If you want the frame to resize instead of guessing, have the app post its height to the parent and have the parent set it. A `window.parent.postMessage({h: document.body.scrollHeight})` on the inside and a `message` listener on the outside is about fifteen lines, and it is the difference between a scrollbar inside a scrollbar and a page that reads as one.
One header check to run before you promise anyone this works: open your published app's response headers and look for `X-Frame-Options` or a `frame-ancestors` directive. A site that sends either will refuse to frame. Checked on 8 October 2026, tjalam.com, which is built with Lovable, sends neither, so a published Lovable app frames normally.
WordPress.com support, captured 8 October 2026. The iframe tag is filtered out on the free plan, and a paid plan alone is not enough.
On self-hosted WordPress, add a Custom HTML block, paste the iframe, publish. Nothing else to do.
On WordPress.com it is not that simple, and this is where most people lose an hour. The Custom HTML block documentation states that tags including `iframe`, `script`, `style`, `form`, `embed` and `object` require a paid plan with hosting features activated, and that a paid plan alone is not enough: you also have to install at least one plugin to activate hosting features. Until both are true, the iframe silently disappears when you save, with no error.
Use the Embed element. Wix support is unusually direct about what it is: the HTML and URL elements in the editor are iframes. You can either paste the code or enter the website address, and both produce the same frame.
Two constraints from the same page. Only HTTPS code and URLs display, which is never a problem with a modern host. And because the element is an iframe, embedded content is not responsive even when the source is, so set width and height to 100 percent and size the element itself on each breakpoint rather than expecting it to adapt.
Use a Code Block. The Squarespace documentation says plain text, HTML, Markdown and CSS work on all plans, but JavaScript and iframes require the Core, Plus, Advanced, Business, Commerce Basic or Commerce Advanced plan.
Then the detail that sends people to support: code may not appear while you are logged in, as a security measure, even though visitors can see it. Use Preview in Safe Mode before concluding the embed is broken. Code on a page inside an Index may not render at all, so pull the page out of the Index to test.
| Host | Element | Plan needed for an iframe | The thing that catches people |
|---|---|---|---|
| Self-hosted WordPress | Custom HTML block | None | Nothing, it just works |
| WordPress.com | Custom HTML block | Paid plan AND hosting features active | Tag vanishes on save with no error |
| Wix | Embed element | Not stated in the support article | Frame is not responsive, set 100% and size per breakpoint |
| Squarespace | Code Block | Core, Plus, Advanced, Business or Commerce | Invisible while logged in, use Preview in Safe Mode |
All four rows read from the platforms' own support pages on 8 October 2026.
Widget vendors price by impressions. That is the whole argument in one sentence, and it is the reason the parking meter analogy holds. A page that does well costs more to run than a page nobody reads.
Calconic's pricing page, read on 8 October 2026 on annual billing and excluding VAT, lists four tiers:
| Plan | Price | Active calculators | Impressions per month |
|---|---|---|---|
| Free | $0 forever | 5 | 500 |
| Light | $5 per month | 10 | 3,000 |
| Regular | $14 per month | 20 | 15,000 |
| Bold | $44 per month | Unlimited | 75,000 |
500 page views a month is the entire free tier. A single post that lands on page one of a search result burns through it in a weekend, and the calculator stops rendering for everyone after that.
Read the ladder as a traffic tax rather than a software price. At 15,000 views a month you are on $14. At 80,000 you are above the published tiers and into a conversation. The tool has not changed. Only the number of people who saw it has.
The Lovable plan cards, read logged out on 8 October 2026. Prices move, so re-check the page on the day rather than trusting any article, including this one.
The owned route prices differently. Read logged out on 8 October 2026, Lovable's monthly plans are Free at $0, Pro from $25 a month for 100 credits and Business from $50 a month for 100 credits, with Enterprise on volume-based pricing. The Pro credit ladder runs 100 credits at $25 up to 10,000 at $2,250, and the Business ladder runs 100 at $50 up to 10,000 at $4,300 with a 14 percent saving at the top rung. The billing toggle offers two months free on yearly.
Nothing on that ladder is priced per visitor. Hosting a published app is covered for most small or new apps by the included grant, so the marginal cost of the ten-thousandth person who opens your calculator is zero. The full plan-by-plan breakdown lives in our Lovable pricing comparison.
Where the free widget wins: a brochure site with light traffic, nobody technical, and no appetite for maintaining anything. Five hundred views a month is genuinely enough for a small local page, and a free widget beats an unmaintained custom build every time.
Where owning wins: traffic that grows, a calculator that needs to look like the rest of the site, outputs a vendor does not offer, or any requirement to keep what visitors enter out of a third party's systems. The last one is the quiet decider for anyone in a regulated line of work. On the owned route the code is yours and portable, as set out in exporting a Lovable app to GitHub and Vercel.
A customer-facing calculator on your main site is a different job from an internal tool only your team should open. If the second is what you need, the access controls that matter are on the Business plan, and the plan comparison for finance teams sets out which ones.
A calculator is a statement about money, and it will be read as one. Four rules keep an interactive tool on the right side of that line. None of them is legal advice, and none of them names a regulator, because the duties recur in nearly every jurisdiction under different names.
Put the words next to the number, not in a footer nobody scrolls to. Something plain works best: Illustration only. Based on the figures you entered. Not a quote, an offer or an approval. A reader who screenshots the result should be screenshotting the label too.
The interest rate is what the formula uses, the price of borrowing the principal. The APR is a broader figure that folds in fees, points and some closing costs, which is why it is usually higher than the interest rate on the same loan. A calculator that accepts an APR and runs it through the monthly payment formula overstates the payment. Label the field interest rate, say what it is, and if you also show an APR, show it as a separate output.
A default rate in an empty field is fine, as long as it is labelled as a sample. A field headed your rate with a number already in it reads as a personalised indication of what someone would be offered, and nobody is in a position to make that claim from four anonymous inputs. Label it sample rate or today's typical rate with the date beside it, and let the visitor overwrite it.
A calculator published by a firm that arranges or advises on loans is marketing, and in most places that means it needs the same review as any other marketing. Build it, then get it signed off before it goes live, and keep a dated copy of what was approved. Advisers publishing any client-facing tool will find the wider pattern in our guide to advisor websites, and the intake side of it in client onboarding portals.
One more habit worth keeping: do not store what you do not need. A calculator that works entirely in the browser, with no inputs sent anywhere, is the easiest version of this problem to solve, and it is the default unless you deliberately add a backend.
Principal and interest is rarely what lands in someone's account. Property tax, home insurance, mortgage insurance and association fees can add a third again on top. A calculator that omits them is not wrong, it is just answering a smaller question than the visitor asked, and the visitor finds out later.
Hard-coding 500 pixels and hoping is the most common embed failure. The amortisation table expands, the result panel grows, and visitors get a tiny scroll region inside your page. Either set a generous height or post the real height to the parent.
An iframe keeps whatever width it was given. Set `max-width:100%` on the frame and test at 360 pixels, which is still the width a large share of visitors are using. A calculator that forces the host page to scroll sideways is worse than no calculator.
Run the five test rows above against anything you build or buy, before launch and after every change. An AI-assisted build can quietly regress an exponent during an unrelated edit, and nothing on screen will look wrong.
Rates move, defaults go stale, and a sample rate from eighteen months ago makes a current page look abandoned. Put a dated line under the calculator and a recurring reminder in a calendar.
Two routes. Sign up with a widget vendor, configure the calculator in their dashboard and paste the embed code they give you. Or build your own, publish it at its own address, and drop a single iframe into a Custom HTML block, Wix Embed element or Squarespace Code Block. The second route costs nothing per visitor and gives you control of the outputs and the styling.
Yes, several vendors offer a free tier, but the limits are the point. Calconic's free plan, read on 8 October 2026, allows five active calculators and 500 impressions a month. That suits a low-traffic page and fails the moment a post does well. A self-hosted calculator has no impression limit at all.
M = P x i / (1 - (1 + i)^-n), where P is the principal, i is the annual rate divided by 12 and n is the number of monthly payments. A $300,000 loan at 6.5 percent over 30 years gives $1,896.20 a month. Use that as a test value for any calculator.
On self-hosted WordPress, yes, through a Custom HTML block with no restrictions. On WordPress.com the iframe tag requires a paid plan with hosting features activated, which means installing at least one plugin as well as paying. Without both, the tag is stripped out when you save.
They help engagement, which is the honest version of the claim. An interactive tool keeps people on the page longer and earns links more readily than a static table. They do not rank by themselves: the head terms for calculators are held by very large sites, so a calculator usually earns its keep as a supporting asset on a page that ranks for something more specific.
Put one on regardless. Label the output as an illustration based on the figures entered, and state plainly that it is not a quote or an approval. If your firm arranges, lends or advises, treat the calculator as marketing and route it through whatever sign-off process your other marketing goes through.
Rent the widget if the page is small and quiet and you want it done this afternoon. Five hundred views a month is a real allowance and a free tier that works beats a custom build nobody maintains.
Own the calculator if the traffic is going anywhere. The parking meter charges by the visitor and keeps charging as the page succeeds. The driveway is laid once. With a template that already handles the amortisation, the insurance drop-off and the payoff maths, laying it is an afternoon, and after that every visitor is free.
If you want to try the owned route, you can start building with Lovable on the free plan and only move up when the project needs it. Teams that need internal publishing, role-based access and single sign-on around a client-facing tool will want the Business plan, and you can book time with TJ through the Lovable Expert directory if you would rather have the first version built with you.
For the wider picture on where this platform fits, and where it does not, read our full Lovable review for 2026. For a different build in the same shape, an invoice app without code covers the same publish-and-embed ground with a form instead of a formula.
TJ Alam is a certified Lovable Expert on the Website Builder track and the founder of Digi Flock Enterprises. He built tjalam.com and cyberdance.in with Lovable. You can find his listing on the Lovable Expert directory, or start a project with Lovable directly.
MoneyFlock may earn a commission if you subscribe to a Lovable Business plan through links in this article, at no extra cost to you. TJ Alam is a certified Lovable Expert.