API marketplace

Fertilizer maths as an API, computed locally and deterministically. The rate endpoint works out how much fertilizer product to apply to hit a target nitrogen rate over an area: from the N-P-K analysis (such as 10-10-10 or 20-5-10), a target pounds of nitrogen per 1000 ft² (or per 100 m²) and the area, it returns the product weight and the pounds of nitrogen, phosphate and potash applied. The nutrients endpoint reports the pounds of nitrogen, P₂O₅ and K₂O — and the elemental phosphorus and potassium — in a bag of a given weight and analysis. The coverage endpoint works out how much area a bag covers at a target nitrogen rate. N-P-K are percent by weight; phosphorus is reported as P₂O₅ and potassium as K₂O following the label convention, with the elemental amounts alongside (P₂O₅ × 0.4364, K₂O × 0.8301). Everything is computed locally and deterministically, so it is instant and private. Ideal for lawn-care and gardening apps, agriculture and turf tools, and landscaping and quoting software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is fertilizer rate maths; for mulch, gravel and topsoil quantities use a landscaping API.

Uptime

100.0%

Latency

202ms

Subs

4,512

Slope and grade maths as an API, computed locally and deterministically. The convert endpoint converts a slope between every common form — percent grade, angle in degrees, a ratio such as 1:12, per mille and rise-per-run — where the slope m = rise ÷ run = tan(angle). The distance endpoint relates the run (horizontal), the rise (vertical) and the slope distance (the hypotenuse) of a right-triangle slope: give any two, optionally with the grade or angle, and it returns the rest. The ramp endpoint sizes a wheelchair or ADA ramp — from a rise and a maximum slope (defaulting to 1:12, the ADA maximum of 8.33%) it returns the required run and total ramp length, and if you supply an actual run it checks whether the ramp is within the limit. Everything is computed locally and deterministically, so it is instant and private. Ideal for civil-engineering and surveying tools, road, trail and accessibility apps, construction and ramp design, and mapping software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is slope and grade geometry; for roof pitch specifically use a roofing API.

Uptime

100.0%

Latency

175ms

Subs

3,042

Water-hardness maths as an API, computed locally and deterministically. The convert endpoint converts a hardness value between all the common units — parts per million / milligrams per litre as calcium carbonate, grains per US gallon, German degrees (°dH), French degrees (°f), English or Clark degrees, and millimoles per litre — passing everything through ppm (1 gpg = 17.118 ppm, 1 °dH = 17.848, 1 °f = 10, 1 °Clark = 14.254), and classifies the result. The classify endpoint labels a value as soft, moderately hard, hard or very hard on the USGS/WHO scale. The softener endpoint sizes a water softener: from the hardness and the household water use it works out the grains of hardness removed per day and the grain capacity needed between regenerations. Everything is computed locally and deterministically, so it is instant and private. Ideal for water-treatment and plumbing tools, aquarium and pool apps, appliance and softener sizing, and home and lab software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is water-hardness conversion; for general unit conversion use a unit-conversion API and for swimming-pool dosing use a pool API.

Uptime

100.0%

Latency

165ms

Subs

3,880

Wi-Fi channel maths as an API, computed locally and deterministically from the standard channel-numbering formulas. The channel endpoint returns the centre frequency of a Wi-Fi channel on the 2.4, 5 or 6 GHz band — the band is auto-detected from the channel number or can be given explicitly (2.4 GHz: 2407 + 5·channel, with channel 14 at 2484; 5 GHz: 5000 + 5·channel; 6 GHz: 5950 + 5·channel). The frequency endpoint does the reverse, returning the nearest channel and band for a centre frequency in MHz or GHz. The overlap endpoint reports whether two channels overlap at a chosen channel width (two channels overlap when their centre-frequency separation is less than the width) and gives the recommended non-overlapping set — the classic 1, 6 and 11 on 2.4 GHz at 20 MHz. Everything is computed locally and deterministically, so it is instant and private. Channel availability is regulated and varies by country. Ideal for networking and Wi-Fi tools, site-survey and IoT apps, and router and access-point configuration software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is Wi-Fi channel mapping; for general wavelength/frequency and photon energy use a wavelength API.

Uptime

100.0%

Latency

175ms

Subs

4,228

Single-course grade maths as an API, computed locally and deterministically — the everyday "what do I need on the final" student calculations. The needed endpoint works out the score required on the final exam (or any remaining component) to reach a target overall grade, from the current grade and the weight the final carries, and flags whether the target is achievable or already secured. The projected endpoint gives the overall grade you would finish with for a hypothetical final score. The average endpoint computes the weighted average of graded components from a simple score:weight list (such as 90:40,80:60), and reports the total and remaining weight so you can see how much of the course is still ungraded. Percentages run 0–100 and weights accept either a percentage (30) or a fraction (0.3). Everything is computed locally and deterministically, so it is instant and private. Ideal for student and study apps, learning-management tools, and tutoring and education sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is single-course grade mechanics; for a multi-course grade-point average from credit hours use a GPA API.

Uptime

100.0%

Latency

155ms

Subs

4,933

Staircase geometry as an API, computed locally and deterministically. The calc endpoint takes the total rise (floor-to-floor height) and works out the number of steps, the exact riser height, the tread depth, the total run, the stringer (hypotenuse) length and the stair angle, and checks the result against building-code limits and the Blondel comfort rule (2 × riser + tread ≈ 24–25 in). The check endpoint validates a given riser and tread against typical US IRC limits — maximum riser 7.75 in, minimum tread 10 in — and reports the angle and comfort. The stringer endpoint returns the stringer length and angle from a total rise and total run. Dimensions are handled internally in inches but accept inches, centimetres, millimetres and metres. Everything is computed locally and deterministically, so it is instant and private. Code limits are typical US IRC values — always confirm your local building code. Ideal for construction and carpentry tools, deck and home-improvement apps, and architecture and CAD software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is staircase geometry; for paint, tile and concrete quantities use a construction-calculator API and for roof pitch use a roofing API.

Uptime

100.0%

Latency

156ms

Subs

3,995

Antenna length maths as an API, computed locally and deterministically. The dipole endpoint gives the total and per-leg length of a half-wave dipole for a frequency, in metres, feet, inches and centimetres, applying a velocity factor (about 0.95 for wire) and also reporting the classic 468 ÷ f(MHz) feet rule of thumb. The quarterwave endpoint gives the element length of a quarter-wave vertical or monopole, with the 234 ÷ f(MHz) rule. The element endpoint computes the length of an element at any fraction of a wavelength — full-wave, half-wave, quarter-wave, fifth-wave, five-eighths or a custom fraction. Frequencies accept Hz, kHz, MHz and GHz, and the velocity factor is configurable. Everything is computed locally and deterministically, so it is instant and private. These are starting lengths: real antennas need trimming and tuning for the lowest SWR, as end effects and surroundings shift the resonant length. Ideal for amateur-radio and RF tools, antenna and IoT design, and electronics education. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is antenna geometry; for general wavelength, frequency and photon energy use a wavelength API.

Uptime

100.0%

Latency

195ms

Subs

3,063

Electromagnetic-wave maths as an API, computed locally and deterministically. The convert endpoint converts between wavelength and frequency (λ = c ÷ f) and also reports the period, the wavenumber, the photon energy and the part of the spectrum — optionally for light travelling in a medium of a given refractive index, where the wavelength scales by 1/n while the frequency stays the same. The energy endpoint gives the photon energy in joules, electron-volts and kilo-electron-volts from a wavelength or frequency (E = h·f = h·c ÷ λ). The band endpoint classifies a wavelength or frequency into the electromagnetic spectrum — radio, microwave, infrared, visible, ultraviolet, X-ray or gamma — and adds the ITU radio sub-band (ELF through EHF) and the approximate colour for visible light. Frequencies accept Hz/kHz/MHz/GHz/THz and wavelengths m/cm/mm/µm/nm/pm/ångström. Everything is computed locally and deterministically, so it is instant and private. Ideal for RF and antenna tools, optics and photonics, spectroscopy and lab software, physics and astronomy education, and amateur radio. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is electromagnetic-wave physics; for general unit conversion use a unit-conversion API.

Uptime

100.0%

Latency

193ms

Subs

3,007

Blood-type compatibility as an API, covering the ABO and Rh(D) systems, computed locally and deterministically. The compatibility endpoint says whether a given donor can give to a given recipient, for both red blood cells and plasma — the red-cell rule being that the donor's antigens must be a subset of the recipient's (Rh included), and plasma being the reverse and ignoring Rh. The info endpoint describes a blood type: the antigens it carries, the antibodies in its plasma, every type it can receive red cells from and donate red cells to, who it can give plasma to, whether it is a universal red-cell donor (O−), universal red-cell recipient (AB+) or universal plasma donor (AB), and its approximate US population frequency. The donors endpoint lists every compatible donor type for a recipient, for red cells or plasma. Blood types are accepted in many forms (O-, O neg, AB positive, …). Everything is computed locally and deterministically, so it is instant and private. This is educational only — real transfusion requires laboratory cross-matching and clinical judgement, and it is not medical advice. Ideal for medical-education and first-aid apps, blood-donation and health tools, and quiz and reference sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is ABO/Rh compatibility; for a drug reference database use a drug API.

Uptime

100.0%

Latency

153ms

Subs

4,209

Caffeine metabolism maths as an API, computed locally and deterministically with a first-order (exponential) decay model. The level endpoint computes how much caffeine remains in the body after a given time from a dose and a half-life (about 5 hours by default), as milligrams and a percentage, and how long until it falls to a chosen threshold. The timeline endpoint returns an hour-by-hour decay curve and the time until caffeine is "sleep safe" — below a threshold (50 mg by default) — handy for working out a coffee cut-off before bed. The sources endpoint gives the typical caffeine content of common drinks (brewed coffee, espresso, tea, energy drinks, cola and more) for a single drink, or totals a list such as two coffees and a cola. Everything is computed locally and deterministically, so it is instant and private. This is informational only: real caffeine half-life varies widely between people (roughly 3–7 hours, and much longer in pregnancy or with certain medications) — it is not medical advice. Ideal for coffee, sleep and wellbeing apps, energy-drink and habit trackers, and quantified-self tools. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is caffeine pharmacokinetics; for a drug reference database use a drug API.

Uptime

100.0%

Latency

180ms

Subs

3,652

Fencing material estimating as an API, computed locally and deterministically. The posts endpoint works out the number of fence sections, line posts and rails for a run from its length and the post spacing, plus the total rail length. The pickets endpoint computes how many pickets or boards a length needs from the picket width and the gap between boards (set the gap to zero for a privacy fence). The materials endpoint produces a full bill of materials in one call — posts, rails, pickets and the concrete for the post holes, in cubic feet and metres and in 80 lb pre-mix bags — from the fence dimensions and the hole size and post depth. Everything is computed locally and deterministically, so it is instant and private. These are estimates: allow extra for waste, gates and corner posts, and follow your local building code for post depth and footing size. Picket width and gap are in inches; length can be feet, yards or metres. Ideal for fencing contractors and estimators, DIY and home-improvement tools, and landscaping and quoting software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is fencing materials; for paint, tile and concrete use a construction-calculator API and for mulch and gravel use a landscaping API.

Uptime

100.0%

Latency

162ms

Subs

3,191

HVAC sizing maths as an API, computed locally and deterministically from standard rule-of-thumb factors. The cooling endpoint estimates the air-conditioner load for a room — in BTU per hour, tons of cooling and kilowatts — from the floor area (in square feet or metres, or length × width) using a baseline of about 20 BTU/h per square foot, with adjustments for the number of occupants, a kitchen, sun exposure and ceiling height. The heating endpoint estimates the heating load from the area and a climate zone (mild through very cold) or a custom BTU per square foot. The convert endpoint converts between BTU per hour, tons of cooling, kilowatts and watts (one ton = 12,000 BTU/h ≈ 3.517 kW). Everything is computed locally and deterministically, so it is instant and private. These are rule-of-thumb estimates in the EnergyStar style — a proper Manual J load calculation accounting for insulation, windows and local climate is recommended for a real installation. Ideal for HVAC and home-improvement tools, air-conditioner and heater sizing guides, smart-home and energy apps, and contractor quoting. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is HVAC sizing; for appliance running cost use an energy-cost API.

Uptime

100.0%

Latency

183ms

Subs

4,645

Pipe-flow maths as an API, computed locally and deterministically. The flow endpoint relates the three quantities of pipe flow — volumetric flow rate, fluid velocity and pipe diameter — through the continuity relation Q = A·v (with A = π/4·D²): give any two and it returns the third, with the flow rate expressed in litres per second and minute, cubic metres per hour, US gallons per minute and cubic feet per minute, plus the velocity and the pipe cross-section. The reynolds endpoint computes the Reynolds number from velocity, diameter and the fluid (water, air, oil and more, or a custom kinematic viscosity) and classifies the flow as laminar, transitional or turbulent. The convert endpoint converts a flow rate between litres per second and minute, cubic metres per hour, US gallons per minute, cubic feet per minute and per second. Everything is computed locally and deterministically, so it is instant and private. It is computed in SI internally; Reynolds uses the kinematic viscosity at about 20°C. Ideal for plumbing and HVAC tools, pump and irrigation sizing, process and fluid-engineering software, and hydraulics calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is fluid flow in pipes; for plain volume or unit conversion use a unit-conversion API.

Uptime

100.0%

Latency

159ms

Subs

4,789

Firewood maths as an API, computed locally and deterministically. The volume endpoint turns a wood-stack's length, height and depth (in feet or metres) into its volume in cubic feet and cubic metres, full cords, face cords and steres — a full cord being 128 cubic feet (a 4×4×8 ft stack) and a face cord being an 8×4 ft stack by the piece (log) length. The convert endpoint converts a quantity between cords, face cords, steres, cubic metres and cubic feet, using the piece length for the face-cord relationship. The heat endpoint estimates the heating value of a number of cords by wood species — returning the millions of BTU and the equivalent gallons of heating oil, therms of natural gas and kilowatt-hours — from a built-in table of typical seasoned-wood values (oak, hickory, maple, ash, birch, pine and more) or a custom figure. Everything is computed locally and deterministically, so it is instant and private. Heat values are typical seasoned figures (around 20% moisture) and vary with species, dryness and stove efficiency. Ideal for firewood sellers and delivery tools, heating and homestead apps, and forestry and woodlot calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is firewood volume and energy; for general volume or unit conversion use a unit-conversion API.

Uptime

100.0%

Latency

172ms

Subs

4,795

Bicycle gearing maths as an API, computed locally and deterministically. The gear endpoint takes a chainring and cog tooth count and a wheel size and returns every common gearing metric: the gear ratio, gear inches (the classic measure — ratio times wheel diameter in inches), the gain ratio (Sheldon Brown's crank-length-aware measure), the development or rollout (metres travelled per crank revolution), and the road speed at a chosen cadence in km/h and mph. The speed endpoint converts between a gear-and-cadence and road speed in either direction — the speed at a cadence, or the cadence needed for a target speed. The table endpoint builds a gear chart: give one or more chainrings and a cassette of cogs and it returns a matrix of gear inches, development, gain ratio or ratio for every combination — ideal for visualising a drivetrain. Wheel size can be a preset (700x25c, 26-inch, 29er and more) or an exact rolling circumference in millimetres, and crank length is configurable for the gain ratio. Everything is computed locally and deterministically, so it is instant and private. Ideal for cycling apps and bike-fit tools, drivetrain and gear-ratio planners, and bike-shop and component sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is bicycle gearing; for cycling power, FTP and training zones use a cycling API.

Uptime

100.0%

Latency

170ms

Subs

4,493

Bolt and fastener torque maths as an API, using the standard short-form relation T = K · D · F — torque equals the nut factor times the bolt diameter times the clamp load (preload). The torque endpoint computes the tightening torque, in newton-metres, foot-pounds, inch-pounds and kilogram-force metres, from the bolt diameter, the target clamp load and a nut factor — given directly or chosen from a condition preset (dry, lubricated, zinc-plated, galvanized, waxed and more). The preload endpoint solves the inverse: the clamp load a given torque produces on a bolt of a given diameter and friction. The convert endpoint converts a torque value between newton-metres, foot-pounds, inch-pounds and kilogram-force metres. Everything is computed locally and deterministically, so it is instant and private. The K·D·F short form is an estimate that depends heavily on friction — it is engineering guidance only, so always follow the manufacturer's torque specification. Ideal for mechanical, automotive and aerospace tools, maker and assembly apps, maintenance and field-service software, and engineering calculators. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is fastener torque; for wire gauge and resistance use a wire-gauge API and for Ohm's law use an electronics API.

Uptime

100.0%

Latency

171ms

Subs

4,977

Unit-price and best-value maths as an API — the supermarket "which is cheaper" calculation, computed locally and deterministically and entirely currency-agnostic. The unit endpoint normalises a pack price to a price per standard unit: from a price, a pack size and its unit (and an optional multipack count) it returns the price per kilogram, per 100 g and per pound for weight; per litre, per 100 ml and per fluid ounce for volume; or per item for counted goods — plus the price per pack item for multipacks. The compare endpoint takes several pack options as a simple list (such as "3@500g,5@1kg,4.5@750g"), ranks them cheapest-per-unit first, names the best value and reports the percentage saving versus the most expensive. The convert endpoint turns a unit price given in one basis (for example per pound) into the other bases for its measure. Everything is computed locally and deterministically, so it is instant and private. Options being compared must share a measure (all weight, all volume or all count). Ideal for shopping and grocery apps, price-comparison and deal sites, budgeting tools, and retail and procurement software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is unit-price comparison; for profit margin and markup use a margin API.

Uptime

100.0%

Latency

161ms

Subs

3,777

Electricity cost maths as an API, computed locally and deterministically and entirely currency-agnostic. The cost endpoint works out an appliance's energy use and running cost from its power (watts or kilowatts), the hours used per day and a per-kilowatt-hour tariff — returning the kilowatt-hours and the cost per day, week, month and year, with an optional quantity of identical devices. The compare endpoint pits two appliances against each other: it computes each one's annual energy cost, the saving from the more efficient one, and — given the extra purchase price of the better model — the payback period in years and months. The convert endpoint relates watts, hours and kilowatt-hours: give any two and it returns the third, plus the cost at a tariff. Everything is computed locally and deterministically, so it is instant and private. Kilowatt-hours equal power in kilowatts times hours, and cost equals kilowatt-hours times the rate; months use 365/12 days. Ideal for energy-saving and smart-home apps, appliance comparison and retail tools, sustainability dashboards, and budgeting software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is energy-cost maths; for battery capacity and runtime use a battery API.

Uptime

100.0%

Latency

146ms

Subs

4,490

American Wire Gauge maths as an API, computed locally and deterministically from the AWG definition. The awg endpoint takes a gauge — an integer, or 0/00/000/0000 (1/0–4/0) — and returns the conductor diameter (millimetres, inches, mils), the cross-section area (mm², kcmil and circular mils), the DC resistance per kilometre and per 1000 feet for copper and aluminium, and a typical ampacity. The convert endpoint finds the nearest standard AWG for a given cross-section area, diameter or kcmil, and also reports the exact non-integer gauge. The voltage-drop endpoint computes the round-trip voltage drop and power loss for a wiring run from the gauge (or area), length, current and conductor material, with the percentage drop and the voltage left at the load. Everything is computed locally and deterministically, so it is instant and private. Resistances are at 20°C; ampacity figures are typical guidance only — real installations are governed by the NEC/IEC tables for the conductor, insulation and conditions. Ideal for electrical and electronics tools, maker and hobby projects, solar and automotive wiring, and AV and installation planning. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is wire-gauge physics; for Ohm's-law voltage/current/resistance use an electronics API and for resistor colour bands use a resistor API.

Uptime

100.0%

Latency

176ms

Subs

3,499

Pizza and bread dough maths as an API, built on baker's percentages — where the flour is always 100% and every other ingredient is expressed as a percentage of the flour weight. The dough endpoint computes a full recipe in grams (flour, water, salt, yeast, oil and sugar) from a target quantity — either a number of dough balls and a ball weight, a total dough weight, or a flour weight — together with a hydration and salt/yeast percentages, or a built-in style preset (Neapolitan, New York, Detroit, Sicilian, focaccia, ciabatta, baguette, sandwich). The hydration endpoint converts between flour, water and hydration percentage and classifies the dough from stiff to extremely wet. The presets endpoint returns the common dough styles as baker's percentages with typical ball weights. Everything is computed locally and deterministically, so it is instant and private. The yeast figure is instant dry yeast (use roughly three times as much fresh). Ideal for recipe and baking apps, pizzeria and bakery tools, meal-planning and kitchen-scale integrations, and food blogs. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is dough formulation by baker's percentage; for ingredient volume-to-weight and oven-temperature conversion use a cooking API.

Uptime

100.0%

Latency

159ms

Subs

3,002

Lighting design maths as an API, computed locally and deterministically. The room endpoint works out how many lumens a room needs from its area and a target illuminance — given directly in lux or chosen from a room-type preset (living, kitchen, office, workshop and more) — and, optionally, how many fixtures at a given lumen output and how many watts at a given lamp type. The lux endpoint converts between lux, footcandles and lumens over an area, so you can find the illuminance from a light output and a room size or vice versa. The efficacy endpoint relates lumens, watts and luminous efficacy (lumens per watt): give any two — or a lamp-type preset such as incandescent, halogen, CFL or LED — and it computes the third. Everything is computed locally and deterministically, so it is instant and private. It is a lumen-method estimate: target levels are typical guidance (EN 12464 / IES) and a full design would add room and utilisation factors. Ideal for lighting and electrical tools, interior-design and home apps, retrofit and energy-saving calculators, and smart-home planning. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is illumination maths; for Ohm's-law electrical quantities use an electronics API.

Uptime

100.0%

Latency

176ms

Subs

4,612

Roofing geometry as an API, computed locally and deterministically. The pitch endpoint converts a roof pitch between every common form — rise-over-run (such as 6:12), the angle in degrees, the percent slope, and the slope multiplier (the factor that turns a flat footprint into the real sloped area). The rafter endpoint computes the rafter length from the horizontal run and the pitch — that is, the hypotenuse √(run² + rise²) — with an optional overhang projected along the slope. The area endpoint computes the true sloped roof area from the building footprint (entered directly or as length × width) and the pitch, adds a wastage allowance, and reports the number of US roofing squares and shingle bundles needed. Everything is computed locally and deterministically, so it is instant and private. Lengths are unit-agnostic — use consistent units — while the squares and bundles figures assume US roofing squares of 100 square feet, so pass the footprint in square feet for those. Ideal for roofing contractors and estimators, construction and DIY tools, solar-install planning, and quoting software. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is roof geometry; for paint, tile, concrete and brick quantities use a construction-calculator API.

Uptime

100.0%

Latency

182ms

Subs

4,431

Screen and display pixel-density maths as an API, computed locally and deterministically. The ppi endpoint computes the pixels per inch of a display from its resolution and diagonal size — along with the pixels per centimetre, the dot pitch in millimetres, the diagonal in pixels, the total pixels and megapixels, the simplified aspect ratio, and the physical width and height. The size endpoint does the inverse: from a resolution and a known PPI it works out the physical dimensions and diagonal in inches and centimetres. The retina endpoint analyses a display at a viewing distance: it computes the pixels per degree, says whether the display is effectively "retina" (pixels indistinguishable to 20/20 vision, around 60 pixels per degree), and gives the distance at which it becomes retina. Everything is computed locally and deterministically, so it is instant and private. Ideal for display and monitor tools, AV and signage planning, UI and responsive-design work, and hardware comparison sites. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is screen pixel density; for print resolution and image-to-print sizing use a DPI API.

Uptime

100.0%

Latency

163ms

Subs

3,799

Progressive (marginal) tax-bracket maths as an API. You supply the bracket schedule, so it works for any country, year or tax table and never goes stale, and it is entirely currency-agnostic. The tax endpoint takes an income and a schedule of threshold:rate pairs (with an optional standard deduction) and returns the total tax, the after-tax income, the effective and marginal rates, and a per-bracket breakdown showing exactly how much is taxed in each tier. The reverse endpoint solves the inverse problem — the gross income needed to take home a target net amount on the same schedule — by bisection. The brackets endpoint validates and normalizes a schedule into labelled tiers (adding a 0% tier from zero and marking the open-ended top bracket). Everything is computed locally and deterministically, so it is instant and private. It models only the schedule you provide — fold any allowances, credits or surtaxes into the brackets or the deduction yourself — and it is not tax advice. Ideal for payroll and HR tools, salary and offer calculators, fintech and budgeting apps, and any product that shows take-home pay. Pure local computation — no key, no third-party service, instant. Live, nothing stored. 3 endpoints. This is progressive-tax maths on a schedule you supply; for gross-pay period conversion use a payroll API and for loans and interest use a finance-calculator API.

Uptime

100.0%

Latency

139ms

Subs

4,769