DEV Community: Peptide Library

How a Peptide Blend Calculator Should Handle Multi-Peptide Vials (Math, Code and Input Checks)

Peptide Library — Fri, 13 Nov 2026 15:19:00 +0000

Short answer: a peptide blend calculator is a single-peptide calculator run once per component, with one shared diluent volume. Each component's concentration is its own mass ÷ the shared volume, and any volume you draw carries every component in a ratio that was fixed when the vial was made. The arithmetic is simple. The bugs live in the inputs: labels that don't say whether "10 mg" means each component or the total, "total" vs "per-component" targets, mixed units, and IU entries with no conversion factor.

Disclosure: I'm affiliated with Peptide Library, which is published by Superfime LLC and has a blend mode in its web calculator. This post is about modelling and validating the math, and the code is standalone. It's for research and lab recordkeeping only. It is not medical advice, and no number here is a suggested amount of anything for anyone.

Why blends deserve their own post

A single-peptide reconstitution calculator has one mass, one volume and one target. A blend vial has N masses, one volume, and a target that can mean two different things. Search behaviour shows people want this specifically: in Ahrefs' US data (pulled 13 November 2026), "peptide calculator for blends" shows about 800 monthly searches and "peptide blend calculator" about 600 (KD 25). Many calculators that rank for those terms either don't support more than one component or quietly treat the blend as one substance. Both give wrong per-component figures.

The model

Say a vial contains components A, B, … with masses m_A, m_B, … (mg), and diluent volume V (mL) is added.

Quantity	Formula
Concentration of component i	c_i = m_i ÷ V (mg/mL)
Total concentration	c_total = Σ m_i ÷ V
Ratio (fixed)	m_A : m_B : … (independent of V)
Component i in a draw of v mL	c_i × v
U-100 syringe units for v mL	v × 100

Two consequences matter for UI design:

Water changes concentrations, never the ratio. Doubling V halves every c_i, but A:B stays the same. A calculator should show the ratio as a fixed property of the vial, not something the user can edit after mixing.
You can't target one component without moving the others. Pick a volume to hit a quantity of B, and A comes along in proportion. The calculator should always display every component for any computed draw, never only the one the user asked about.

A worked example (hypothetical lab numbers, arithmetic only)

Hypothetical test vial: A = 6 mg, B = 2 mg, diluent V = 2 mL.

c_A = 6 ÷ 2 = 3 mg/mL; c_B = 2 ÷ 2 = 1 mg/mL; c_total = 4 mg/mL; ratio A:B = 3:1.
A 0.10 mL draw (10 units on a U-100 scale) contains 0.30 mg (300 mcg) of A and 0.10 mg (100 mcg) of B.

Now the two target modes, using a test input of 400 mcg:

Total mode ("400 mcg of blend"): v = 0.4 mg ÷ 4 mg/mL = 0.10 mL. Split by ratio: 300 mcg A + 100 mcg B.
Per-component mode ("400 mcg of B"): v = 0.4 mg ÷ 1 mg/mL = 0.40 mL, which also carries 1.2 mg of A.

Same input, a 4× difference in volume. That's why the mode must be an explicit, visible choice. Peptide Library's blend tool, for example, has a "Total dose / Per component" toggle. In your own build, never default it silently.

The label problem

Before any arithmetic, a blend calculator needs a clean answer to: is the labelled mass per component or total? A "10 mg" two-component vial could hold 10 mg of each (20 mg total) or 10 mg total (perhaps 5 + 5, perhaps not). Vendors aren't consistent, and Peptide Library's FAQ on how blend labels can mislead makes the same point. The calculator can't resolve it. It can refuse to guess: require per-component masses, or require the user to pick "each" vs "total" plus a ratio.

A typed implementation

Dependency-free TypeScript. Everything runs internally in micrograms (1 mg = 1,000 mcg by SI prefix definition; see NIST's prefix table). Every result also returns warnings.

type MassUnit = "mcg" | "mg" | "iu";

interface Component {
  name: string;
  amount: number;          // as labelled
  unit: MassUnit;
  mcgPerIU?: number;       // required if unit === "iu"; substance-specific
}

interface BlendInput {
  components: Component[];
  diluentMl: number;
}

type Target =
  | { mode: "total"; mcg: number }
  | { mode: "component"; name: string; mcg: number };

const MAX_COMPONENTS = 8;

function toMcg(c: Component): number {
  if (c.unit === "mcg") return c.amount;
  if (c.unit === "mg") return c.amount * 1000;
  if (!c.mcgPerIU || c.mcgPerIU <= 0) {
    throw new Error(`${c.name}: IU needs a substance-specific mcg-per-IU factor`);
  }
  return c.amount * c.mcgPerIU;
}

export function validate(input: BlendInput): string[] {
  const errors: string[] = [];
  const n = input.components.length;
  if (n < 2) errors.push("A blend needs at least 2 components; use single mode.");
  if (n > MAX_COMPONENTS) errors.push(`At most ${MAX_COMPONENTS} components.`);
  const names = input.components.map(c => c.name.trim().toLowerCase());
  if (new Set(names).size !== names.length) errors.push("Duplicate component names.");
  for (const c of input.components) {
    if (!Number.isFinite(c.amount) || c.amount <= 0) errors.push(`${c.name}: amount must be > 0.`);
    if (c.unit === "iu" && !(c.mcgPerIU! > 0)) errors.push(`${c.name}: IU without a conversion factor.`);
  }
  if (!Number.isFinite(input.diluentMl) || input.diluentMl <= 0) errors.push("Diluent volume must be > 0 mL.");
  return errors;
}

export function concentrations(input: BlendInput) {
  const errs = validate(input);
  if (errs.length) throw new Error(errs.join(" "));
  const masses = input.components.map(c => ({ name: c.name, mcg: toMcg(c) }));
  const totalMcg = masses.reduce((s, m) => s + m.mcg, 0);
  return {
    totalMcgPerMl: totalMcg / input.diluentMl,
    perComponent: masses.map(m => ({
      name: m.name,
      mcgPerMl: m.mcg / input.diluentMl,
      fraction: m.mcg / totalMcg,          // the fixed ratio
    })),
  };
}

export function draw(input: BlendInput, target: Target) {
  const conc = concentrations(input);
  const warnings: string[] = [];
  let ml: number;
  if (target.mode === "total") {
    ml = target.mcg / conc.totalMcgPerMl;
  } else {
    const c = conc.perComponent.find(p => p.name === target.name);
    if (!c) throw new Error(`Unknown component ${target.name}`);
    ml = target.mcg / c.mcgPerMl;
  }
  if (ml > input.diluentMl) warnings.push("Requested volume exceeds the vial's contents.");
  const units = ml * 100;                   // U-100 scale
  if (Math.abs(units - Math.round(units)) > 1e-9) {
    warnings.push(`${units.toFixed(2)} units falls between whole-unit marks.`);
  }
  return {
    ml,
    units,
    contains: conc.perComponent.map(p => ({ name: p.name, mcg: p.mcgPerMl * ml })),
    warnings,
  };
}

Design choices worth copying:

contains always lists every component. A UI that shows only the targeted component hides the most important fact about a blend.
fraction comes from mass, not from user input. If users can type a ratio and masses separately, the two will eventually disagree.
IU is per component. One blend can mix IU-labelled and mass-labelled components, and each IU needs its own factor. Never apply one global factor.
Round only at display time. Compute in full precision and format at the end, so rounding errors don't compound across components.

Test vectors

These are hypothetical arithmetic checks, not amounts anyone should use.

Case	Input	Expected
Ratio is volume-independent	A 6 mg, B 2 mg; V = 1, 2, 4 mL	fraction A = 0.75 every time
Total mode	same vial, V = 2 mL, total 400 mcg	0.10 mL, 10 units; A 300 mcg, B 100 mcg
Component mode	same vial, V = 2 mL, B 400 mcg	0.40 mL; A 1,200 mcg
Unit mixing	A 6 mg + B 2,000 mcg, V = 2 mL	identical to A 6 mg + B 2 mg
Between marks	A 5 mg, B 5 mg, V = 3 mL, total 250 mcg	0.075 mL, 7.5 units → warning
Over-draw	V = 1 mL, request needing 1.2 mL	warning, not a silent cap
Bad input	1 component, 0 mL, IU without factor, duplicate names	rejected with a reason each

If your total-mode and component-mode tests pass for the same vial but the "Ratio is volume-independent" test fails, you're probably recomputing the fraction from rounded concentrations. Use masses.

What the math does not tell you

A calculator assumes every component dissolves fully, the labelled masses are accurate, and nothing degrades. Those are lab questions, not arithmetic ones. Whether two peptides are chemically compatible and stable in one solution (pH, aggregation, degradation over time) has to be established empirically for that combination, and per-component identity and purity testing is a separate concern from the math. A blend calculator also says nothing about clinical evidence. Laboratory data on a component, a combination's popularity, and human clinical evidence are different things. For many combinations sold as blends, no published human study of the combination exists.

Where to try it

If you want to check your implementation against an existing tool, Peptide Library's peptide research calculator has Single, Blend and Cost modes in the browser. Blend mode handles up to eight components with a total vs per-component toggle (on the website, blend mode is part of the Pro plan). Its two-component blend page shows a per-component concentration table at several diluent volumes. That table makes a handy cross-check for the "ratio is volume-independent" test, and the page deliberately shows concentrations only, with no dose table.

Takeaways

Model a blend as N masses sharing one volume. Concentrations are per component, and the ratio is fixed at mixing.
Make "total" vs "per component" an explicit choice, because it can change the computed volume by a large factor.
Refuse ambiguous inputs (each vs total labelling, IU without a factor, one-component "blends") instead of guessing.
Always show every component in the result.

Research and educational use only. Not medical advice. Nothing in this post is a recommended amount, schedule or use of any substance. Affiliation: Peptide Library is published by Superfime LLC.

The Math Behind a Peptide Reconstitution Calculator (and How to Test It)

Peptide Library — Thu, 12 Nov 2026 15:39:20 +0000

Short answer: a peptide reconstitution calculator does four lines of arithmetic: concentration = mass ÷ diluent volume, volume = amount ÷ concentration, U-100 syringe units = mL × 100, and count per vial = vial mass ÷ amount. The arithmetic is easy. Most bugs come from the parts around it: unit conversion (mg vs mcg vs IU), floating-point display, rounding to a syringe scale, and inputs that should be rejected rather than "calculated".

Disclosure: I'm affiliated with Peptide Library, which is published by Superfime LLC and runs a free web calculator. This post is about the engineering, and the code below is standalone. Everything here is for research and lab recordkeeping only. It is not medical advice, and no number in this post is a suggested amount of anything.

Why this is worth a post

Search demand for this kind of tool is large. Ahrefs' US data (November 2026) shows about 11,000 monthly searches for "peptide reconstitution calculator" and over 200,000 for "peptide calculator". Most of the tools that rank are single-page forms with no tests and no visible formulas. If you build one, the bar for correctness should be higher than "it printed a number".

This post walks through the model, the unit handling, a TypeScript implementation, and the test cases I'd consider the minimum.

The model: four formulas and one unit rule

A lyophilized (freeze-dried) vial holds a fixed mass of powder. Adding a known volume of diluent turns it into a solution with a known concentration. From there, everything follows:

Quantity	Formula	Unit
Concentration	vial mass ÷ diluent volume	mg/mL
Volume for an amount	amount ÷ concentration	mL
U-100 syringe units	volume × 100	units
Count per vial	vial mass ÷ amount	(dimensionless)

The unit rule is that everything is converted to one internal mass unit before any division. Most visible errors in these tools come from mixing milligrams and micrograms. 1 mg = 1,000 mcg, by SI prefix definition. NIST's metric prefix reference is a good thing to link in your code comments so nobody "fixes" it later.

IU (international units) is different. IU is not an SI unit, and the mass-per-IU factor is specific to each substance. A calculator should never assume a universal IU-to-mg factor. Either require the factor as an input or attach it to a specific, documented reference entry. If you don't have a factor, refuse the conversion.

What "U-100" means for the display

A U-100 insulin syringe is graduated so that 100 units = 1 mL, which is why the conversion is a factor of 100. The syringe itself constrains the output. Common barrel sizes are 0.3 mL, 0.5 mL and 1 mL, and the readable gradation differs by barrel. A good calculator shows the exact computed value and flags when that value falls between markings, instead of silently rounding.

A typed implementation

Here's a minimal, dependency-free TypeScript version. It works in integer micrograms internally and returns structured results with warnings.

type MassUnit = "mg" | "mcg";

const MCG_PER: Record<MassUnit, number> = { mg: 1000, mcg: 1 };

export interface ReconInput {
  vialMass: number;        // e.g. 5
  vialUnit: MassUnit;      // "mg"
  diluentMl: number;       // e.g. 2.5
  amount: number;          // e.g. 500
  amountUnit: MassUnit;    // "mcg"
  syringeMl?: 0.3 | 0.5 | 1;
}

export interface ReconResult {
  concentrationMgPerMl: number;
  volumeMl: number;
  u100Units: number;
  countPerVial: number;
  warnings: string[];
}

const toMcg = (v: number, u: MassUnit) => v * MCG_PER[u];

export function reconstitute(i: ReconInput): ReconResult {
  const warnings: string[] = [];
  for (const [k, v] of Object.entries(i)) {
    if (typeof v === "number" && (!Number.isFinite(v) || v <= 0)) {
      throw new RangeError(`${k} must be a positive, finite number`);
    }
  }

  const vialMcg = toMcg(i.vialMass, i.vialUnit);
  const amountMcg = toMcg(i.amount, i.amountUnit);
  if (amountMcg > vialMcg) {
    throw new RangeError("amount exceeds the total mass in the vial");
  }

  const concMcgPerMl = vialMcg / i.diluentMl;
  const volumeMl = amountMcg / concMcgPerMl;
  const units = volumeMl * 100;

  const syringe = i.syringeMl ?? 1;
  if (volumeMl > syringe) {
    warnings.push(`volume ${volumeMl.toFixed(3)} mL exceeds a ${syringe} mL barrel`);
  }
  if (units < 1) {
    warnings.push("result is below 1 unit on a U-100 scale; hard to read accurately");
  }

  return {
    concentrationMgPerMl: concMcgPerMl / 1000,
    volumeMl,
    u100Units: units,
    countPerVial: vialMcg / amountMcg,
    warnings,
  };
}

A few deliberate choices:

Reject, don't coerce. Zero, negative, NaN and Infinity inputs throw. A calculator that returns Infinity mL because someone typed 0 for diluent is worse than one that shows an error.
Amount larger than vial is an error, not a result of "0.8 vials".
Warnings are data, so the UI can render them next to the number instead of burying them in a toast.

Floating point: where "correct" math prints wrong numbers

JavaScript numbers are IEEE 754 doubles, so 0.1 + 0.2 !== 0.3. Python's docs have the clearest short explanation of why: see Floating-Point Arithmetic: Issues and Limitations. For a calculator this shows up two ways:

Display drift. A volume computed as 0.25000000000000006 should display as 0.25. Format at the edge (toFixed, Intl.NumberFormat) and keep full precision internally.
Comparisons. Never compare computed doubles with === in tests. Use a tolerance. Number.EPSILON (MDN) is the gap between 1 and the next representable double. For values around 1-100, a relative tolerance like 1e-9 is more practical.

export const close = (a: number, b: number, rel = 1e-9) =>
  Math.abs(a - b) <= rel * Math.max(1, Math.abs(a), Math.abs(b));

Display rules that prevent misreads

Medication-safety groups have documented for decades how numbers get misread. ISMP's (now ECRI's) list of error-prone abbreviations and dose designations is directly relevant to UI design, even for research tools:

No trailing zeros (5.0 can be read as 50).
Always a leading zero (.5 can be read as 5; show 0.5).
Avoid "µg", which is easy to misread as "mg". Spell out "mcg".
Put the unit right next to every number. A bare "0.25" in a results card is ambiguous.

I'd encode these as a formatter and test it as carefully as the math:

export function fmt(n: number, unit: string, maxDp = 3): string {
  const s = n.toFixed(maxDp).replace(/\.?0+$/, ""); // strip trailing zeros
  return `${s.startsWith(".") ? "0" + s : s} ${unit}`;
}

Test vectors

These are arbitrary arithmetic fixtures. They check the math and are not amounts anyone should use.

Vial	Diluent	Amount	Expected conc.	Expected volume	Expected units	Count
5 mg	2.5 mL	500 mcg	2 mg/mL	0.25 mL	25	10
10 mg	4 mL	1 mg	2.5 mg/mL	0.4 mL	40	10
2 mg	1 mL	100 mcg	2 mg/mL	0.05 mL	5	20

import { reconstitute } from "./recon";
import { close } from "./close"; // the tolerance helper above

test("5 mg / 2.5 mL / 500 mcg", () => {
  const r = reconstitute({ vialMass: 5, vialUnit: "mg", diluentMl: 2.5, amount: 500, amountUnit: "mcg" });
  expect(close(r.concentrationMgPerMl, 2)).toBe(true);
  expect(close(r.volumeMl, 0.25)).toBe(true);
  expect(close(r.u100Units, 25)).toBe(true);
  expect(close(r.countPerVial, 10)).toBe(true);
});

test("rejects zero diluent", () => {
  expect(() => reconstitute({ vialMass: 5, vialUnit: "mg", diluentMl: 0, amount: 1, amountUnit: "mg" }))
    .toThrow(RangeError);
});

test("rejects amount larger than vial", () => {
  expect(() => reconstitute({ vialMass: 1, vialUnit: "mg", diluentMl: 1, amount: 2, amountUnit: "mg" }))
    .toThrow(RangeError);
});

Other cases worth covering:

Unit symmetry: amount: 0.5, amountUnit: "mg" must equal amount: 500, amountUnit: "mcg".
Round trip: volume × concentration should return the original amount within tolerance.
Property tests: for random positive inputs, countPerVial × amount === vialMass (within tolerance). A tool like fast-check makes this cheap.
Formatter: fmt(0.5, "mL") === "0.5 mL", fmt(5, "mg") === "5 mg" (no 5.000), and .25 never appears.

What the calculator can't tell you

It's worth being explicit, in the UI and in docs, about what the arithmetic doesn't cover:

It doesn't verify what's in the vial. The mass on a label is a claim. Purity and identity testing is a separate lab question, and a correct calculation on a mislabeled vial is still wrong.
It is not evidence of anything. For many research peptides, published data is mostly preclinical (cell and animal studies), with little or no controlled human data. The FDA's page on bulk drug substances that may present significant safety risks in compounding lists several popular peptides, including BPC-157, and notes limited or missing safety information. Keep "the math is right" and "the substance is studied in humans" clearly apart in your copy.
It's not a recommendation engine. A research calculator should take the amount as user input and never suggest one.

Platform note: why some iOS apps dropped calculators

If you ship this in a native iPhone app, read Apple's App Review Guideline 1.4.2. It says drug dosage calculators must come from a drug manufacturer, hospital, university, health insurer, pharmacy or other approved entity, or be approved by the FDA or an international counterpart. Most independent developers are none of those things. Peptide Library is one app that changed course: its App Store release notes for version 2.9.4 say it "removed all the calculators from the iPhone app to comply with App Store policy".

The browser is a different distribution channel. A web calculator can be added to the iPhone Home Screen as a web app, which is the route Peptide Library's web calculator documents for iOS users. If you go that way, the testing above matters even more, because no app review sits between your code and the user.

What I learned

Write the formulas into the UI. When users can see "mass ÷ volume = concentration", they catch their own input mistakes.
Spend as much time on rejection paths and formatting as on the math. They're where the real-world errors are.
Keep the domain claims out of the calculator. Its job is arithmetic, clearly labeled, with units on every number.

If you want to compare your implementation's output against a working reference, the online peptide calculator on Peptide Library shows the same four formulas on the page. It's a quick way to sanity-check a test vector.

Research and educational use only. Not medical advice. Nothing in this post is a recommended amount, schedule or use of any substance. Affiliation: Peptide Library is published by Superfime LLC.