Skip to main content

Module 1 — Interface: inputs, outputs, function

Gradio has one job: take a Python function and put a web page in front of it, so that a colleague, a client or a recruiter can try the model in their browser without a Python setup on their side. Everything else in this course — Blocks, chat, streaming, queueing, hosting — is an extension of that idea. This first module locks down the smallest possible demo and explains what each piece does.

The three arguments that matter

gr.Interface takes three arguments: the function to call, the input component or list of components, and the output component or list of components. That is the entire mental model. Every other option is a decoration around this triple.

import gradio as gr

def greet(name: str) -> str:
return f"Hello, {name}!"

demo = gr.Interface(
fn=greet,
inputs="text",
outputs="text",
title="A minimal Gradio demo",
description="Type a name and Gradio calls the Python function for you.",
)

demo.launch()

Run this file with python app.py and Gradio opens a local server on http://127.0.0.1:7860. The page has a text box wired to the input, a submit button, and a text panel for the output. Click submit and Gradio serializes the input, calls greet, and paints the returned string. If your function raises, the traceback appears both in the terminal and, briefly, in the UI — a small detail that saves hours during development.

From Python type to component

The strings "text", "image", "audio", "video", "number", "checkbox", "slider" and a dozen more are convenient shortcuts. Behind each one sits a full component class — gr.Textbox, gr.Image, gr.Audio, gr.Number, and so on — that you can instantiate directly whenever you need to set parameters. The two calls below are equivalent, and only the second lets you customize the widget:

# Short form
demo = gr.Interface(greet, "text", "text")

# Explicit form, room to configure
demo = gr.Interface(
greet,
inputs=gr.Textbox(label="Your name", placeholder="Ada", lines=1),
outputs=gr.Textbox(label="Greeting"),
)

The rule to remember: inputs becomes positional arguments of your function, in order, and outputs receives whatever the function returns. A function that takes two arguments needs a list of two input components; a function that returns a tuple needs a list of two output components. Any mismatch surfaces as a clear error at launch time, not at request time.

The image classifier in ten lines

The course's red thread starts here: the image classifier from course 10. Assume you already have a trained model, either a scikit-learn pipeline, a Keras model, a PyTorch module or a Hugging Face pipeline. The demo boils down to feeding an image to the model and returning a dictionary of probabilities.

import gradio as gr
from transformers import pipeline

classifier = pipeline("image-classification", model="google/vit-base-patch16-224")

def classify(image):
predictions = classifier(image)
return {p["label"]: float(p["score"]) for p in predictions}

demo = gr.Interface(
fn=classify,
inputs=gr.Image(type="pil", label="Upload an image"),
outputs=gr.Label(num_top_classes=5, label="Top classes"),
title="Image classifier",
description="A pretrained Vision Transformer, wrapped in ten lines of code.",
allow_flagging="never",
)

demo.launch()

Two design decisions here deserve to be spelled out. First, gr.Image(type="pil") tells Gradio to hand the function a PIL.Image.Image rather than a NumPy array or a file path. That decision belongs to the model — the next module details the three formats and when to use each. Second, returning a dictionary with gr.Label gives the horizontal bar display that everyone recognizes from Hugging Face demos, complete with sorted scores and a "top-k" cutoff. Return a plain string and you would get flat text; the choice of output component controls what the user sees.

Title, description and article

title, description and article are the three text fields Gradio renders around your demo. title sits above the interface; description sits between the title and the widgets, in plain text or Markdown, and is the right place to say what the model does and what it does not do; article renders below the interface and accepts Markdown, so it is where longer notes, caveats, licenses and citations belong. Fill at least the description on any demo you share externally: it is what stands between an impressed reviewer and one who thinks the model is broken because they fed it something it was never designed for.

Launch, live, share

The launch call has two switches worth knowing from the start. Setting debug=True keeps the notebook cell alive and prints logs; setting share=True returns a public *.gradio.live URL that anyone on the internet can hit for seventy-two hours. Course 08 is entirely devoted to the tradeoffs of that share link, so we simply note here that it exists.

In summary

  • gr.Interface(fn, inputs, outputs) is the entire foundation of Gradio: everything else configures those three pieces.
  • The order of inputs maps to positional arguments; outputs catches the return value. A function of two arguments needs two input components.
  • Choose the output component deliberately: a dictionary plus gr.Label gives ranked bars, a string gives flat text — the widget dictates the experience.
  • Populate at least description: it tells reviewers what your demo is meant for and what to expect when they push it.

Next module: what each component receives, in what shape, so that the function you plug in does the right thing on the first try.