Virtual Try-On for Universities: Career Fairs, Photo Booths & Student Events

Walk onto any campus during career-fair week and you see the same quiet anxiety. A student has an interview slot in an hour, a resume in hand, and no clear idea what they look like in a blazer they have never worn. They picture the outfit; they cannot see it. That small gap between imagining and seeing is exactly where AI virtual try-on has quietly become one of the most popular attractions at university events worldwide.

The idea is simple. A student steps up to a screen, their photo is captured, and within seconds they see themselves wearing a professional suit, a graduation gown, a lab coat, or a company uniform. No changing room. No borrowed jacket. No awkward mirror selfie. Just a clear, shareable image of themselves in the outfit, generated on the spot.

This guide is written for the people who actually run these experiences: career-services teams, student unions, event organizers, and the student developers who build photo booths for campus fairs. It covers where try-on fits on a campus, the four ways to run it, the exact code to build your own booth in React, Next.js, PHP, or Python, and a pricing model built for events, where prepaid credits never expire, so you never pay for a generation you do not use.

Why Campuses Are Adopting Try-On Right Now

For years, virtual try-on lived in fashion ecommerce. The technology was built to reduce clothing returns for online stores. But the same engine that shows an online shopper a jacket on their body turns out to solve a completely different problem on a university campus: helping young people picture themselves in a role before they step into it.

A career fair is fundamentally about imagination. Recruiters ask students to imagine themselves at the company. Students ask themselves whether they belong in that world. Seeing yourself in the outfit closes part of that loop. It is a small psychological nudge with an outsized effect on confidence, and confidence is the difference between a nervous handshake and a memorable one.

• ✓Interactive draw, a live booth pulls foot traffic that static banners never will
• ✓Confidence tool, students see themselves in professional attire before interviews
• ✓Shareable output, each result photo is content the student posts, extending reach
• ✓Sponsor value, a recruiting company can brand the booth and the outfit set
• ✓Zero friction, no app, no sign-up, no changing room for the student

Where Virtual Try-On Fits on a Campus

The career fair is the obvious starting point, but it is only one of many moments where seeing yourself in an outfit matters. Once you have the engine, the same booth serves the entire academic year.

One booth, many uses. A university that sets up try-on for a spring career fair can redeploy the exact same setup for graduation season, autumn open days, and every departmental event in between. The prepaid credits do not expire between events, so the investment carries across the whole calendar.

How a Student Try-On Actually Works

Under the hood, every try-on is two images going in and one image coming out. You provide a photo of the person and a photo of the garment, and the engine returns a new image of that person wearing that garment, with their face, pose, body, and background preserved. Nothing about the student is changed except the clothes.

Because the whole flow is capture, select, generate, there is nothing for the student to download and no account for them to create. That is what makes it work at the pace of a live event: the line keeps moving, and every person walks away with their image.

Four Ways to Run Virtual Try-On at Your Event

There is no single right setup. The best choice depends on whether you want something running in ten minutes with no code, or a fully branded booth built by your student developers. Here are the four approaches, from simplest to most custom.

Photo-Booth & Kiosk Mode: The Fastest Way to Go Live

Kiosk mode turns any tablet or laptop with a camera into a self-contained try-on booth. It is designed for exactly the situation a campus event creates: one device, a steady stream of people, and an attendant who wants the line to move. The student steps in front of the camera, the photo is captured, an outfit is chosen, and the result appears. There is no per-student login and no app to hand out.

Because one physical device serves many people all day, kiosk mode is priced and built around a shared booth rather than a single user. You load your outfit set once, set a daily limit if you want one, and let it run. It is the closest thing to a plug-in photo booth for professional attire.

Scan & Pay Booths: When the Booth Charges Per Photo

Some events want the booth to pay for itself. A scan & pay booth lets each student pay a small amount for their try-on photo directly at the booth, usually by scanning a code with their phone. The payment is handled per generation, so the organizer collects the money and only the try-ons that are actually paid for are run.

This is a natural fit for student-run ventures and society fundraisers, where a booth doubles as a revenue stream. Students queue, scan, pay a token fee, and receive their professional-outfit photo. The organizer sees the collected total, and the booth funds itself over the course of the event.

Build Your Own Booth With the Developer API

For student developers and computer-science societies, the most rewarding option is to build the booth yourself. The Developer API is the raw try-on engine exposed as a single REST endpoint: one request in with a person image and a garment image, one finished image out. Everything around it, the camera capture, the outfit picker, the branding, the print or email step, is yours to design.

This is deliberately unopinionated. You are not forced into a template. You can build a full-screen React booth for a tablet, a Next.js web app students open on their own phones, a Python desktop app for a laptop at the fair, or a PHP page embedded in your student portal. The engine does not care what language calls it.

Code: React, Next.js, PHP & Python

The pattern is identical in every language: send the person image and the garment image to the endpoint with your API key, receive the finished image. The one rule that matters for a public booth is that your API key must live on a server you control, never in browser code where a visitor could read it. In practice that means a tiny proxy: your booth front-end talks to your own small server, and that server talks to the try-on endpoint.

Next.js: a secure server route

In a Next.js booth, put the key in a server route so it is never exposed to the tablet running the front-end.

// app/api/tryon/route.ts  (server-side, key stays secret)
export async function POST(req: Request) {
  const { personImage, garmentImage } = await req.json()

  const res = await fetch("https://www.tryoncloud.com/api/v1/generate", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.TRYON_API_KEY}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ person_image: personImage, garment_image: garmentImage }),
  })

  // The endpoint returns the finished PNG bytes.
  const image = await res.arrayBuffer()
  return new Response(image, { headers: { "Content-Type": "image/png" } })
}

React: the booth front-end

The tablet captures a photo and posts it to your own route above. It never sees the key.

async function runTryOn(personImage, garmentImage) {
  const res = await fetch("/api/tryon", {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ personImage, garmentImage }),
  })
  const blob = await res.blob()
  return URL.createObjectURL(blob) // show it full-screen at the booth
}

PHP: for a portal or WordPress booth

<?php // tryon.php, server-side
$payload = json_encode([
  "person_image"  => $personImageBase64,
  "garment_image" => $garmentImageBase64,
]);

$ch = curl_init("https://www.tryoncloud.com/api/v1/generate");
curl_setopt_array($ch, [
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_POST => true,
  CURLOPT_POSTFIELDS => $payload,
  CURLOPT_HTTPHEADER => [
    "Authorization: Bearer " . getenv("TRYON_API_KEY"),
    "Content-Type: application/json",
  ],
]);
$imageBytes = curl_exec($ch); // finished PNG
curl_close($ch);
?>

Python: for a desktop booth app

import os, requests

def run_tryon(person_b64, garment_b64):
    r = requests.post(
        "https://www.tryoncloud.com/api/v1/generate",
        headers={"Authorization": f"Bearer {os.environ['TRYON_API_KEY']}"},
        json={"person_image": person_b64, "garment_image": garment_b64},
    )
    with open("result.png", "wb") as f:   # finished image
        f.write(r.content)
    return "result.png"

That is the entire integration. Four languages, one endpoint, the same three moving parts every time: a person image, a garment image, and your key kept on the server. Whatever booth experience you dream up on top of that is yours to build.

Credits That Never Expire: A Model Built for Events

Events are spiky. You need a lot of capacity for three days and almost none for the rest of the term. A monthly subscription punishes that shape, you pay every month whether or not you run a single try-on, and any unused allowance resets to zero. The Developer API takes the opposite approach.

Credits are prepaid and never expire. There is no monthly reset and no expiry date. You buy a batch sized to your expected attendance, use what the event actually needs, and whatever is left stays in your account for the next event. One generation costs one credit, so your spend maps exactly to how many students walked up to the booth.

Event-Day Checklist

A try-on booth is only as good as its setup on the day. This short checklist keeps the line moving and the results looking sharp.

• ✓Prepare your outfit set in advance, clean, front-facing garment images give the best results
• ✓Estimate attendance and buy credits above it; leftovers never expire, so overshooting is safe
• ✓Use a device with a decent front camera on a stable stand at chest height
• ✓Keep a plain, uncluttered area behind the student for the cleanest capture
• ✓Decide how students receive their image: on-screen QR to download, print, or email
• ✓Have an attendant guide the pose, shoulders square to the camera works best
• ✓Test the full flow the day before, including the print or email step
• ✓Brand the screen with your event and any sponsor before doors open

Student Privacy Comes First

Handling students’ photos responsibly is not optional for an institution, so the data model is deliberately minimal. The photo a student provides is deleted immediately after their result image is generated, it is not retained. The finished result is held for seven days so the student can view or download it again, then permanently deleted. No photo is ever used to train any model.

For a campus deployment, that means you can tell students the truth plainly: their photo is used to make their image and nothing else, it is not stored beyond generation, and the result disappears within a week. Pair the booth with clear on-screen consent and a short notice, and you have a setup that respects the people using it.

How It Compares to a Traditional Photo Booth

Universities have rented photo booths for years. They are fun, but they capture the student exactly as they arrive: hoodie, backpack, and all. A virtual try-on booth changes what the camera can show. Instead of freezing the moment, it transforms it, placing the student into the outfit that matches the event. That difference is why organizers who have run both keep choosing try-on for professional and milestone events.

The practical upshot is that a virtual booth has almost no fixed cost. You are not paying to ship a heavy booth or renting it by the day. You run it on a device the department already has, and you pay only for the photos students actually generate. For a budget-conscious student union or a bootstrapped society, that economics is often the deciding factor.

Measuring Whether the Booth Worked

Because every try-on is a counted generation, you get a clean measure of engagement without any extra tracking: the number of credits used is the number of students who tried the booth. That single number is often enough to justify the booth to a department head or a sponsor, but a few soft signals are worth watching too.

• ✓Generations run, the exact count of students who engaged, straight from your credit usage
• ✓Shares and tags, how many result photos students posted with the event name
• ✓Queue length, a consistently busy booth is the clearest sign the draw is working
• ✓Sponsor recall, whether students remember the branded outfit or company at the booth
• ✓Repeat interest, requests to bring the booth to the next department event

A pattern many organizers notice is that the booth pays for itself in intangible ways long before the credits run out. A student who sees themselves in a suit and feels ready for an interview is exactly the outcome career services exists to create, and it happened at a booth that cost a few credits to run. When the event ends, the leftover credits sit ready for the next one, so the value compounds across the academic year rather than resetting each month.

Read next: Add virtual try-on to any React or Next.js app · Instant try-on kiosks & pay-per-try-on